diff options
author | Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com> | 2016-12-12 14:29:08 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2016-12-16 19:31:47 +0100 |
commit | ebe5236d06abcdb1beb93ffbab73557d5b496824 (patch) | |
tree | 14dc107a75f56ea08d97cb64cbc510863dae661e /drivers/net/ethernet/ibm | |
parent | Merge branch 'hisilicon-netdev-dev' (diff) | |
download | linux-ebe5236d06abcdb1beb93ffbab73557d5b496824.tar.xz linux-ebe5236d06abcdb1beb93ffbab73557d5b496824.zip |
encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets
Before, encx24j600_rx_packets did not update encx24j600_priv's next_packet
member when an error occurred during packet handling (either because the
packet's RSV header indicates an error or because the encx24j600_receive_packet
method can't allocate an sk_buff).
If the next_packet member is not updated, the ERXTAIL register will be set to
the same value it had before, which means the bad packet remains in the
component's memory and its RSV header will be read again when a new packet
arrives. If the RSV header indicates a bad packet or if sk_buff allocation
continues to fail, new packets will be stored in the component's memory until
that memory is full, after which packets will be dropped.
The SETPKTDEC command is always executed though, so the encx24j600 hardware has
an incorrect count of the packets in its memory.
To prevent this, the next_packet member should always be updated, allowing the
packet to be skipped (either because it's bad, as indicated in its RSV header,
or because allocating an sk_buff failed). In the allocation failure case, this
does mean dropping a valid packet, but dropping the oldest packet to keep as
much memory as possible available for new packets seems preferable to keeping
old (but valid) packets around while dropping new ones.
Signed-off-by: Jeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/ibm')
0 files changed, 0 insertions, 0 deletions