encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets
authorJeroen De Wachter <jeroen.de_wachter.ext@nokia.com>
Mon, 12 Dec 2016 13:29:08 +0000 (14:29 +0100)
committerDavid S. Miller <davem@davemloft.net>
Fri, 16 Dec 2016 18:31:47 +0000 (13:31 -0500)
commitebe5236d06abcdb1beb93ffbab73557d5b496824
tree14dc107a75f56ea08d97cb64cbc510863dae661e
parentea7a2b9ac853d8c3afd929952ad4b3cb65ba329c
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>
drivers/net/ethernet/microchip/encx24j600.c