[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20161216.133208.2134512725082545132.davem@davemloft.net>
Date: Fri, 16 Dec 2016 13:32:08 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: jeroen.de_wachter.ext@...ia.com
Cc: jringle@...dpoint.com, akpm@...ux-foundation.org,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] encx24j600: bugfix - always move ERXTAIL to next
packet in encx24j600_rx_packets
From: <jeroen.de_wachter.ext@...ia.com>
Date: Mon, 12 Dec 2016 14:29:08 +0100
> From: Jeroen De Wachter <jeroen.de_wachter.ext@...ia.com>
>
> 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@...ia.com>
Applied.
Powered by blists - more mailing lists