[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025072615-espresso-grandson-d510@gregkh>
Date: Sat, 26 Jul 2025 08:36:37 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Yunseong Kim <ysk@...lloc.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Byungchul Park <byungchul@...com>, max.byungchul.park@...il.com,
Yeoreum Yun <yeoreum.yun@....com>,
Michelle Jin <shjy180909@...il.com>, linux-kernel@...r.kernel.org,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Alan Stern <stern@...land.harvard.edu>,
Thomas Gleixner <tglx@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
stable@...r.kernel.org, kasan-dev@...glegroups.com,
syzkaller@...glegroups.com, linux-usb@...r.kernel.org,
linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH] kcov, usb: Fix invalid context sleep in softirq path on
PREEMPT_RT
On Fri, Jul 25, 2025 at 08:14:01PM +0000, Yunseong Kim wrote:
> When fuzzing USB with syzkaller on a PREEMPT_RT enabled kernel, following
> bug is triggered in the ksoftirqd context.
>
> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> | in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 30, name: ksoftirqd/1
> | preempt_count: 0, expected: 0
> | RCU nest depth: 2, expected: 2
> | CPU: 1 UID: 0 PID: 30 Comm: ksoftirqd/1 Tainted: G W 6.16.0-rc1-rt1 #11 PREEMPT_RT
> | Tainted: [W]=WARN
> | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8 05/13/2025
> | Call trace:
> | show_stack+0x2c/0x3c (C)
> | __dump_stack+0x30/0x40
> | dump_stack_lvl+0x148/0x1d8
> | dump_stack+0x1c/0x3c
> | __might_resched+0x2e4/0x52c
> | rt_spin_lock+0xa8/0x1bc
> | kcov_remote_start+0xb0/0x490
> | __usb_hcd_giveback_urb+0x2d0/0x5e8
> | usb_giveback_urb_bh+0x234/0x3c4
> | process_scheduled_works+0x678/0xd18
> | bh_worker+0x2f0/0x59c
> | workqueue_softirq_action+0x104/0x14c
> | tasklet_action+0x18/0x8c
> | handle_softirqs+0x208/0x63c
> | run_ksoftirqd+0x64/0x264
> | smpboot_thread_fn+0x4ac/0x908
> | kthread+0x5e8/0x734
> | ret_from_fork+0x10/0x20
Why is this only a USB thing? What is unique about it to trigger this
issue?
thanks,
greg k-h
Powered by blists - more mailing lists