From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Lizhi Xu <lizhi.xu@windriver.com>
Cc: <alex.aring@gmail.com>, <davem@davemloft.net>,
<dmantipov@yandex.ru>, <edumazet@google.com>,
<horms@kernel.org>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>,
<linux-wpan@vger.kernel.org>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>, <stefan@datenfreihafen.org>,
<syzbot+985f827280dc3a6e7e92@syzkaller.appspotmail.com>,
<syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] mac802154: add a check for slave data list before delete
Date: Wed, 13 Nov 2024 09:26:07 +0100 [thread overview]
Message-ID: <87plmzsfog.fsf@bootlin.com> (raw)
In-Reply-To: <20241112134145.959501-1-lizhi.xu@windriver.com> (Lizhi Xu's message of "Tue, 12 Nov 2024 21:41:45 +0800")
On 12/11/2024 at 21:41:45 +08, Lizhi Xu <lizhi.xu@windriver.com> wrote:
> On Tue, 12 Nov 2024 12:01:21 +0100, Miquel Raynal wrote:
>>On 12/11/2024 at 08:21:33 +08, Lizhi Xu <lizhi.xu@windriver.com> wrote:
>>
>>> On Mon, 11 Nov 2024 20:46:57 +0100, Miquel Raynal wrote:
>>>> On 08/11/2024 at 22:54:20 +08, Lizhi Xu <lizhi.xu@windriver.com> wrote:
>>>>
>>>> > syzkaller reported a corrupted list in ieee802154_if_remove. [1]
>>>> >
>>>> > Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4
>>>> > hardware device from the system.
>>>> >
>>>> > CPU0 CPU1
>>>> > ==== ====
>>>> > genl_family_rcv_msg_doit ieee802154_unregister_hw
>>>> > ieee802154_del_iface ieee802154_remove_interfaces
>>>> > rdev_del_virtual_intf_deprecated list_del(&sdata->list)
>>>> > ieee802154_if_remove
>>>> > list_del_rcu
>>>>
>>>> FYI this is a "duplicate" but with a different approach than:
>>>> https://lore.kernel.org/linux-wpan/87v7wtpngj.fsf@bootlin.com/T/#m02cebe86ec0171fc4d3350676bbdd4a7e3827077
>>> No, my patch was the first to fix it, someone else copied my
>>> patch. Here is my patch:
>>
>>Ok, so same question as to the other contributor, why not enclosing the
>>remaining list_del_rcu() within mutex protection? Can we avoid the
>>creation of the LISTDONE state bit?
> From the analysis of the list itself, we can not rely on the newly added state bit.
> The net device has been unregistered, since the rcu grace period,
> unregistration must be run before ieee802154_if_remove.
>
> Following is my V2 patch, it has been tested and works well.
Please send a proper v2, not an inline v2.
However the new approach looks better to me, so you can add my
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
next prev parent reply other threads:[~2024-11-13 8:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 16:53 [syzbot] [wpan?] [usb?] BUG: corrupted list in ieee802154_if_remove syzbot
2024-11-08 7:17 ` [syzbot] " syzbot
2024-11-08 7:18 ` syzbot
2024-11-08 9:31 ` syzbot
2024-11-08 11:24 ` syzbot
2024-11-08 12:43 ` [syzbot] " syzbot
2024-11-08 14:54 ` [PATCH] mac802154: add a check for slave data list before delete Lizhi Xu
2024-11-11 19:46 ` Miquel Raynal
2024-11-12 0:21 ` Lizhi Xu
2024-11-12 4:31 ` [syzbot] [wpan?] [usb?] BUG: corrupted list in ieee802154_if_remove syzbot
2024-11-12 11:01 ` [PATCH] mac802154: add a check for slave data list before delete Miquel Raynal
2024-11-12 13:41 ` Lizhi Xu
2024-11-13 8:26 ` Miquel Raynal [this message]
2024-11-13 9:51 ` [PATCH V2] mac802154: check local interfaces before deleting sdata list Lizhi Xu
2024-11-19 10:06 ` Stefan Schmidt
2024-11-13 10:29 ` [PATCH] mac802154: add a check for slave data list before delete Dmitry Antipov
2024-11-13 10:58 ` Miquel Raynal
2024-11-13 12:45 ` Dmitry Antipov
2024-11-14 1:00 ` Lizhi Xu
2024-11-14 1:17 ` Lizhi Xu
2024-11-08 16:29 ` [syzbot] Re: BUG: corrupted list in ieee802154_if_remove syzbot
2024-11-09 2:51 ` [syzbot] Re: BUG: corrupted list in ieee802154_if_remove() syzbot
2024-11-12 6:46 ` syzbot
2024-11-12 12:35 ` [syzbot] Re: [syzbot] [wpan?] [usb?] BUG: corrupted list in ieee802154_if_remove syzbot
2024-11-12 13:11 ` syzbot
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=87plmzsfog.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=alex.aring@gmail.com \
--cc=davem@davemloft.net \
--cc=dmantipov@yandex.ru \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=lizhi.xu@windriver.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stefan@datenfreihafen.org \
--cc=syzbot+985f827280dc3a6e7e92@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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.