mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
net: macb: never give hardware a NULL RX buffer
The refill logic is simple: iterate over all pending rx slots, allocate SKB (& DMA map) if needed and hand it off to the hardware by clearing the RX_USED flag. If the refill operation fails mid-way, it early returns leaving the remaining slots untouched. In an initialised ring that is safe: a slot is either owned by the hardware holding a valid buffer, or software-owned (RX_USED set) waiting for refill to hand it a new one. When slots have never been initialised however, we are in trouble. After dma_alloc_coherent() of the rx ring buffer, all slots have NULL pointers and RX_USED cleared meaning HW will try using them. Ensure this does not happen by setting the RX_USED flag on all slots before calling refill at buffer alloc, in gem_init_rx_ring(). That way even if refill fails on an alloc/dma_map, the HW won't try using NULL pointers as buffers. Note we tweak gem_rx() and macb_rx_pending(): their previous stop condition was only if desc was RX_USED. Now it must be either RX_USED or we got out of the range of successfully allocated descriptors (detected using the rx_tail and rx_prepared_head cursors). Otherwise gem_rx() could consume unallocated buffers. Theoretical bugfix, never encountered in practice. To reproduce, introduce memory pressure (less than 512 SKBs of free memory) and open the interface. Note that this codepath also hits at resume, on HRESP errors and on set_ringparam (while interface is running). Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20260925-macb-close-v2-1-360efa565914@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
parent
91abd44838
commit
efd90b64ce
1 changed files with 16 additions and 0 deletions
Loading…
Add table
Add a link
Reference in a new issue