[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANp29Y6NNtie6ZTsFbYUfhubEYW2A-K44B0-TZC=b3+OZcz-Rg@mail.gmail.com>
Date: Fri, 2 Jan 2026 23:02:54 +0100
From: Aleksandr Nogikh <nogikh@...gle.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: syzbot <syzbot+16210d09509730207241@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com,
Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [syzbot] [wireless?] WARNING in rfkill_unregister
On Thu, Jan 1, 2026 at 1:08 PM Johannes Berg <johannes@...solutions.net> wrote:
>
> Hi,
>
> > ------------[ cut here ]------------
> > rtmutex deadlock detected
> > WARNING: kernel/locking/rtmutex.c:1674 at rt_mutex_handle_deadlock+0x21/0xb0 kernel/locking/rtmutex.c:1674, CPU#0: syz.7.2908/15923
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 15923 Comm: syz.7.2908 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> > RIP: 0010:rt_mutex_handle_deadlock+0x21/0xb0 kernel/locking/rtmutex.c:1674
> > Code: 90 90 90 90 90 90 90 90 90 41 57 41 56 41 55 41 54 53 83 ff dd 0f 85 86 00 00 00 48 89 f7 e8 a6 39 01 00 48 8d 3d af 7c 0a 04 <67> 48 0f b9 3a 4c 8d 3d 00 00 00 00 65 48 8b 1c 25 08 10 b3 91 4c
> > RSP: 0018:ffffc90004617710 EFLAGS: 00010286
> > RAX: 0000000080000000 RBX: ffffc900046177a0 RCX: 0000000000000000
> > RDX: 0000000000000006 RSI: ffffffff8ce0bbf9 RDI: ffffffff8ede5760
> > RBP: ffffc900046178c0 R08: ffffffff8edb3477 R09: 1ffffffff1db668e
> > R10: dffffc0000000000 R11: fffffbfff1db668f R12: 1ffff920008c2ef0
> > R13: ffffffff8ad3d599 R14: ffffffff8eb910e0 R15: dffffc0000000000
> > FS: 0000000000000000(0000) GS:ffff888126cef000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000056422df5abe0 CR3: 000000005929c000 CR4: 00000000003526f0
> > Call Trace:
> > <TASK>
> > __rt_mutex_slowlock kernel/locking/rtmutex.c:1734 [inline]
> > __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline]
> > rt_mutex_slowlock+0x666/0x6b0 kernel/locking/rtmutex.c:1800
> > __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline]
> > __mutex_lock_common kernel/locking/rtmutex_api.c:534 [inline]
> > mutex_lock_nested+0x16a/0x1d0 kernel/locking/rtmutex_api.c:552
> > rfkill_unregister+0xd1/0x230 net/rfkill/core.c:1145
> > nfc_unregister_device+0x96/0x300 net/nfc/core.c:1167
> > virtual_ncidev_close+0x59/0x90 drivers/nfc/virtual_ncidev.c:172
>
> NFC has been issues with this for *years*. Technically, Krzysztof is
> listed as a maintainer but I suspect that's mostly dead.
>
> Is there a way you could route rfkill issues to NFC (and have them
> ignored there) if NFC is involved?
It depends on the particular case. It should be fairly easy to do for
warnings (where there's just one clear stack trace) and potentially
very tricky for task hungs (e.g.
https://syzkaller.appspot.com/bug?extid=ef8f802abdb9a32343fc).
>
> Clearly they're not useful if nobody is interested in fixing NFC, so
> maybe we should just disable the virtual NFC driver completely and just
> not have syzbot run on anything there...
>
> If this email doesn't wake anyone up, I'll do that on the next syzbot
> rfkill vs. NFC report I get :)
>
> johannes
>
Powered by blists - more mailing lists