diff options
author | Jakub Kicinski <jakub.kicinski@netronome.com> | 2018-07-21 07:14:39 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-07-22 20:58:52 +0300 |
commit | 07300f774fec9519663a597987a4083225588be4 (patch) | |
tree | cd633e5d64cb7df898460e95a760a1205f76be5a /drivers/net/ethernet/mediatek | |
parent | 042f8825569d628517784d558aefe23c212f0fb2 (diff) | |
download | linux-07300f774fec9519663a597987a4083225588be4.tar.xz |
nfp: avoid buffer leak when FW communication fails
After device is stopped we reset the rings by moving all free buffers
to positions [0, cnt - 2], and clear the position cnt - 1 in the ring.
We then proceed to clear the read/write pointers. This means that if
we try to reset the ring again the code will assume that the next to
fill buffer is at position 0 and swap it with cnt - 1. Since we
previously cleared position cnt - 1 it will lead to leaking the first
buffer and leaving ring in a bad state.
This scenario can only happen if FW communication fails, in which case
the ring will never be used again, so the fact it's in a bad state will
not be noticed. Buffer leak is the only problem. Don't try to move
buffers in the ring if the read/write pointers indicate the ring was
never used or have already been reset.
nfp_net_clear_config_and_disable() is now fully idempotent.
Found by code inspection, FW communication failures are very rare,
and reconfiguring a live device is not common either, so it's unlikely
anyone has ever noticed the leak.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/mediatek')
0 files changed, 0 insertions, 0 deletions