mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®