All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Adi Prasan <itsadi2409@gmail.com>
Cc: alex.aring@gmail.com,  stefan@datenfreihafen.org,
	linux-wpan@vger.kernel.org,  linux-kernel@vger.kernel.org,
	syzbot+adb0bf16414b8bb2d799@syzkaller.appspotmail.com
Subject: Re: [PATCH] mac802154: synchronize pending transmissions before stopping the hardware
Date: Fri, 25 Sep 2026 11:03:24 +0200	[thread overview]
Message-ID: <87ik3tn1nn.fsf@bootlin.com> (raw)
In-Reply-To: <20260920170655.608419-1-itsadi2409@gmail.com> (Adi Prasan's message of "Sun, 20 Sep 2026 17:06:55 +0000")

Hi Adi,

On 20/09/2026 at 17:06:55 GMT, Adi Prasan <itsadi2409@gmail.com> wrote:

> From: Adi <itsadi2409@gmail.com>
>
> syzbot reports a WARN_ON(current_phy->suspended) splat in
> mac80211_hwsim's mac802154 counterpart, hwsim_hw_xmit():
>
>   WARNING: CPU: 0 PID: 6038 at drivers/net/ieee802154/mac802154_hwsim.c:266
>   hwsim_hw_xmit+0xcbf/0x1540
>   Call Trace:
>    drv_xmit_async
>    ieee802154_tx
>    ieee802154_subif_start_xmit
>    __netdev_start_xmit
>    ...
>    packet_sendmsg
>
> mac802154_slave_close() only calls netif_stop_queue() on the closing
> netdev before tearing the hardware down via ieee802154_stop_device(),
> which calls straight into drv_stop(). netif_stop_queue() merely marks
> the queue as stopped; it does not wait for a transmission that a
> different CPU already passed the "is the queue stopped" check for and
> is currently executing inside ndo_start_xmit(). That thread can still
> be inside drv_xmit_async() -> hwsim_hw_xmit() by the time drv_stop()
> runs and marks the phy suspended, which trips the WARN_ON() (and, on
> real hardware, could still start a transmission after ->stop() has
> torn down the transceiver).
>
> ieee802154_suspend() already knows about this and synchronizes with
> any in-flight transmission via ieee802154_sync_and_hold_queue() plus
> synchronize_net() before calling ieee802154_stop_device(), releasing
> the queue again afterwards. mac802154_slave_close() is missing the
> same synchronization when the last open interface on a phy is closed.
>
> Do the same hold/sync/release dance in mac802154_slave_close() so
> drv_stop() cannot race with a transmission that is already in flight.
>
> Reported-by: syzbot+adb0bf16414b8bb2d799@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=adb0bf16414b8bb2d799
> Signed-off-by: Adi <itsadi2409@gmail.com>

We need your real identify.

> ---
>  net/mac802154/iface.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
> index 31353795fa24..e29f225c0dd1 100644
> --- a/net/mac802154/iface.c
> +++ b/net/mac802154/iface.c
> @@ -313,8 +313,19 @@ static int mac802154_slave_close(struct net_device *dev)
>  
>  	clear_bit(SDATA_STATE_RUNNING, &sdata->state);
>  
> -	if (!local->open_count)
> +	if (!local->open_count) {
> +		/* Ensure any asynchronous transmission already accepted by
> +		 * the driver (i.e. past the netif_stop_queue() above) has
> +		 * fully completed before calling into ->stop(). Otherwise
> +		 * drv_xmit_async() can race with drv_stop(), which some
> +		 * drivers (e.g. mac802154_hwsim) do not expect.

hwsim is for testing purposes, not sure this is a real use case.

> This mirrors
> +		 * the synchronization already done in ieee802154_suspend().
> +		 */

This message is 100% AI generated and can be dropped, unless there is a
real info carried, but I don't see it.

Yet, if we can get rid of these by just fixing max802154_hwsim, please
do it.

> +		ieee802154_sync_and_hold_queue(local);
> +		synchronize_net();
>  		ieee802154_stop_device(local);
> +		ieee802154_release_queue(local);
> +	}
>  
>  	return 0;
>  }

Thanks,
Miquèl

  reply	other threads:[~2026-09-25  9:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 17:06 [PATCH] mac802154: synchronize pending transmissions before stopping the hardware Adi Prasan
2026-09-25  9:03 ` Miquel Raynal [this message]
2026-10-02 14:48   ` [PATCH v2] net: mac802154: fix race between slave_close() and in-flight async tx Adi Prasan
2026-10-04 14:46     ` Miquel Raynal

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=87ik3tn1nn.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=alex.aring@gmail.com \
    --cc=itsadi2409@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=stefan@datenfreihafen.org \
    --cc=syzbot+adb0bf16414b8bb2d799@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.