From: Nicolai Buchwitz <nb@tipi-net.de>
To: "Théo Lebrun" <theo.lebrun@bootlin.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Sean Anderson <sean.anderson@linux.dev>,
Antoine Tenart <atenart@kernel.org>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>,
Gregory CLEMENT <gregory.clement@bootlin.com>,
Tawfik Bayouk <tawfik.bayouk@mobileye.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 3/3] net: macb: quiesce IRQs and drain BH on interface close
Date: Mon, 21 Sep 2026 08:55:51 +0200 [thread overview]
Message-ID: <4b1d4821feaf593336cd321b8899d04e@tipi-net.de> (raw)
In-Reply-To: <20260918-macb-close-v1-3-221d916b7961@bootlin.com>
On 18.9.2026 22:32, Théo Lebrun wrote:
> The macb_close() operation is facing races as it disables IRQs late in
> its sequence and keeps BH primitives alive while shutdown.
>
> Non exhaustive list of races that could occur:
>
> - macb_tx_error_task() could be scheduled and access the buffers freed
> by macb_close().
>
> - macb_tx_error_task() or macb_hresp_error_task() might re-enable
> interrupts after the IDR write in macb_close().
>
> - macb_close() calls napi_disable() meaning that if
> macb_tx_error_task() occurs later, it will deadlock on
> napi_disable()
> that shouldn't be called if NAPI is already disabled.
>
> - macb_hresp_error_task() might reinit every RX/TX ring under
> macb_close()'s foot.
>
> - macb_interrupt() might re-enable NAPI just after it has been
> disabled by macb_close().
>
> Instead, disable all our primitives one by one:
> - (1) mask and sync on IRQ handlers,
> - (2) drain any scheduled bp->hresp_err_bh_work,
> - (3) drain any scheduled queue->tx_error_task,
> - (4) drain queue->napi_rx/napi_tx,
> - (5) drain bp->tx_lpi_work.
>
> Careful! Ordering is important because our scheduling primitives can
> wake each other up. Recap table:
>
> | | enable/disable | schedule |
> | |----|-------|-------|------|----|----|--------|-----|
> | |IRQs|napi_tx|napi_rx|tx_lpi|napi|napi|tx_error|hresp|
> | Context | | | | task | rx | tx | task |task |
> |===============|====|=======|=======|======|====|====|========|=====|
> | open | X | X | X | | | | | |
> | link_up | X | | | | | | | |
> | link_down | X | | | | | | | |
> | close | X | X | X | | | | | |
> | enable_tx_lpi | | | | X | | | | |
> | swap | X | X | X | X | | | | |
> | suspend | X | X | X | | | | | |
> | resume | X | X | X | | | | | |
> |---------------|----|-------|-------|------|----|----|--------|-----|
> | irq & netpoll | X | | | | X | X | X | X |
> |---------------|----|-------|-------|------|----|----|--------|-----|
> | napi_rx | X | | | | X | | | |
> | napi_tx | X | | | X | | X | | |
> |---------------|----|-------|-------|------|----|----|--------|-----|
> | tx_error_task | X | X | | | | | | |
> | hresp task | X | | | | | | | |
>
> As example, one ordering constraint that can be deduced from the table:
> napi_tx can schedule tx_lpi_task meaning napi_tx must be disabled
> before tx_lpi_task, else we risk napi_tx re-enabling tx_lpi_task after
> it has been disabled by macb_close().
>
> We do *not* use IDR masking to shutdown IRQs because that risks
> conflicting with BH primitives we have not disabled yet. For example if
> we writel(IDR) in macb_close() and napi_rx is pending then IRQs might
> be unmasked by the NAPI poll. As for why we do not use disable_irq():
> we will have situations where we are quiesced but want to listen to
> some IRQs and (minor reason) we register shared IRQ handlers so we
> shouldn't disable the full IRQ line.
>
> Instead we introduce a bool that tells macb_interrupt() to self-disarm.
> Its default value is true as we start closed. It gets set to false
> while interface is active. Reading into my crystal ball, we'll reuse
> that flag in suspend/WOL, set_ringparam and change_mtu (context swap).
>
> Note that old IRQ handler tried preventing a race with close by
> self-disarming based on netif_running(). This might work, but it does
> not prevent a race with the error codepath of macb_open() which needs
> to run with IRQs dis-armed but netif_running() returns true during that
> time.
>
> Fixes: e86cd53afc59 ("net/macb: better manage tx errors")
> Cc: stable@vger.kernel.org
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> [...]
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Regards
Nicolai
prev parent reply other threads:[~2026-09-21 6:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 20:32 [PATCH 0/3] net: macb: fix close races (and RX refill error handling) Théo Lebrun
2026-09-18 20:32 ` [PATCH 1/3] net: macb: never give hardware a NULL RX buffer Théo Lebrun
2026-09-21 6:54 ` Nicolai Buchwitz
2026-09-18 20:32 ` [PATCH 2/3] net: macb: propagate RX ring refill errors Théo Lebrun
2026-09-21 7:05 ` Nicolai Buchwitz
2026-09-21 9:54 ` Théo Lebrun
2026-09-18 20:32 ` [PATCH 3/3] net: macb: quiesce IRQs and drain BH on interface close Théo Lebrun
2026-09-21 6:55 ` Nicolai Buchwitz [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=4b1d4821feaf593336cd321b8899d04e@tipi-net.de \
--to=nb@tipi-net.de \
--cc=andrew+netdev@lunn.ch \
--cc=atenart@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregory.clement@bootlin.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pabeni@redhat.com \
--cc=sean.anderson@linux.dev \
--cc=stable@vger.kernel.org \
--cc=tawfik.bayouk@mobileye.com \
--cc=theo.lebrun@bootlin.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.kondratiev@mobileye.com \
/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
all inboxes | Powered by JetHome®