Netdev List
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Jakub Raczynski <j.raczynski@samsung.com>, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
	k.domagalski@samsung.com, k.tegowski@samsung.com,
	Chang-Sub Lee <cs0617.lee@samsung.com>
Subject: Re: [PATCH net] net/stmmac: Fix free-after-use panic when interface goes does with XDP
Date: Thu, 14 May 2026 14:01:20 +0200	[thread overview]
Message-ID: <4ca19ae1-6606-433b-9860-0a8cce12f80f@redhat.com> (raw)
In-Reply-To: <20260511165045.3091475-1-j.raczynski@samsung.com>

On 5/11/26 6:50 PM, Jakub Raczynski wrote:
> When running XDP forwarding and interface gets shut down, kernel might panic
> or show SLUB "poison overwritten" errors due to a race condition between
> NAPI polling and resource freeing.
> 
> Observed error is one of following:
> - Poison overwrriten
> [ 1889.547746] eth1: Link is Down
> [ 1889.549940] =============================================================================
> [ 1889.549954] BUG kmalloc-4k (Tainted: G    B             ): Poison overwritten
> [ 1889.549959] -----------------------------------------------------------------------------
> [ 1889.549963] 0xffffff882dcc4d80-0xffffff882dcc4da7 @offset=19840. First byte 0x0 instead of 0x6b
> [ 1889.549969] Allocated in __alloc_dma_tx_desc_resources+0x60/0x10c [stmmac] age=169 cpu=7 pid=27759
> [ 1889.550020]  __kmem_cache_alloc_node+0x100/0x2e8
> [ 1889.550032]  __kmalloc+0x58/0x1a0
> [ 1889.550039]  __alloc_dma_tx_desc_resources+0x60/0x10c [stmmac]
> [ 1889.550052]  alloc_dma_desc_resources+0xec/0x164 [stmmac]
> [ 1889.550064]  stmmac_setup_dma_desc+0xec/0x1e4 [stmmac]
> [ 1889.550076]  stmmac_open+0x28/0x94 [stmmac]
> [...]
> 
> - Wrong memory address
> [ 1901.546692] Unable to handle kernel paging request at virtual address dead000000000122
> [...]
> [ 1902.964068] Call trace:
> [ 1902.967193]  free_to_partial_list+0x560/0x600
> [ 1902.972227]  __slab_free+0x1a8/0x420
> [ 1902.976480]  __kmem_cache_free+0x204/0x218
> [ 1902.981254]  kfree+0x6c/0x128
> [ 1902.984900]  kvfree+0x3c/0x4c
> [ 1902.988545]  page_pool_release+0x234/0x27c
> [ 1902.993320]  page_pool_destroy+0xcc/0x190
> [ 1902.998006]  __free_dma_rx_desc_resources+0x100/0x360 [stmmac]
> [ 1903.004516]  free_dma_desc_resources+0x8c/0xac [stmmac]
> [ 1903.010419]  stmmac_release+0x1c0/0x2b4 [stmmac]
> [...]
> 
> Root cause is stmmac_release() stops DMA and frees TX/RX ring buffers and
> page pools while NAPI/XDP could still be accessing these resources in the
> background.
> 
> Fix this by following:
> - Set STMMAC_DOWN flag before stopping DMA to signal XDP to stop
> - Call synchronize_rcu() after stopping DMA but before freeing resources to
>   ensure all ongoing NAPI operations complete
> - Add STMMAC_DOWN flag checks in XDP code paths (XDP_TX and XDP_REDIRECT) to
>   drop packets when interface is going down. This has already been done for
>   stmmac_xdp_xmit() so make it consistent
> - Clear STMMAC_DOWN flag in __stmmac_open() to restore normal operation.
>   This was only done for stmmac_reset_subtask() during abnormal operation,
>   which is not enough. This does not affect normal operation as this flag is
>   used only for XDP apps

The above looks racy. I think instead you should just use
napi_synchronize() in __stmmac_release.


> @@ -5267,6 +5279,9 @@ static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
>  	if (unlikely(!xdpf))
>  		return STMMAC_XDP_CONSUMED;
>  
> +	if (unlikely(test_bit(STMMAC_DOWN, &priv->state)))
> +		return -ENETDOWN;

Sashiko noted here you should return STMMAC_XDP_CONSUMED

/P


      reply	other threads:[~2026-05-14 12:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260511165107eucas1p1882391435991ffc19670a60a43bbde01@eucas1p1.samsung.com>
2026-05-11 16:50 ` [PATCH net] net/stmmac: Fix free-after-use panic when interface goes does with XDP Jakub Raczynski
2026-05-14 12:01   ` Paolo Abeni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ca19ae1-6606-433b-9860-0a8cce12f80f@redhat.com \
    --to=pabeni@redhat.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=cs0617.lee@samsung.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=j.raczynski@samsung.com \
    --cc=k.domagalski@samsung.com \
    --cc=k.tegowski@samsung.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox