* [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio()
@ 2026-05-23 8:02 w15303746062
2026-05-23 11:08 ` Jeff Layton
0 siblings, 1 reply; 13+ messages in thread
From: w15303746062 @ 2026-05-23 8:02 UTC (permalink / raw)
To: jlayton, chuck.lever, viro, brauner
Cc: alex.aring, jack, linux-fsdevel, linux-kernel, Mingyu Wang
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
send_sigio() when a process group receives a SIGIO.
When FASYNC is configured for a process group (PIDTYPE_PGID),
send_sigio() uses read_lock(&tasklist_lock) to traverse the task
list. However, send_sigio() is often called from softirq context
(e.g., input_inject_event -> kill_fasync), where it already holds
SOFTIRQ-safe locks like &dev->event_lock and &f_owner->lock.
The deadlock is caused by the rwlock writer fairness mechanism:
1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
fork() or exit() and spins, which blocks all new readers.
3. CPU 0 is interrupted by a softirq (e.g., keyboard input event).
4. The softirq calls send_sigio() and attempts to acquire
read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already
RCU-protected, the read_lock on tasklist_lock is no longer strictly
required for safe traversal. Fix this by replacing tasklist_lock with
rcu_read_lock(), aligning the process group signaling path with the
single-PID path.
Lockdep splat:
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
[...]
Chain exists of:
&dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&f_owner->lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK ***
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
fs/fcntl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index beab8080badf..a6c764ede282 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -929,11 +929,11 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
send_sigio_to_task(p, fown, fd, band, type);
rcu_read_unlock();
} else {
- read_lock(&tasklist_lock);
+ rcu_read_lock();
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, type);
} while_each_pid_task(pid, type, p);
- read_unlock(&tasklist_lock);
+ rcu_read_unlock();
}
out_unlock_fown:
read_unlock_irqrestore(&fown->lock, flags);
--
2.34.1
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio()
2026-05-23 8:02 [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio() w15303746062
@ 2026-05-23 11:08 ` Jeff Layton
2026-05-23 13:52 ` [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling w15303746062
0 siblings, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2026-05-23 11:08 UTC (permalink / raw)
To: w15303746062, chuck.lever, viro, brauner
Cc: alex.aring, jack, linux-fsdevel, linux-kernel, Mingyu Wang
On Sat, 2026-05-23 at 16:02 +0800, w15303746062@163.com wrote:
> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
> A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
> send_sigio() when a process group receives a SIGIO.
>
> When FASYNC is configured for a process group (PIDTYPE_PGID),
> send_sigio() uses read_lock(&tasklist_lock) to traverse the task
> list. However, send_sigio() is often called from softirq context
> (e.g., input_inject_event -> kill_fasync), where it already holds
> SOFTIRQ-safe locks like &dev->event_lock and &f_owner->lock.
>
> The deadlock is caused by the rwlock writer fairness mechanism:
> 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
> 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
> fork() or exit() and spins, which blocks all new readers.
> 3. CPU 0 is interrupted by a softirq (e.g., keyboard input event).
> 4. The softirq calls send_sigio() and attempts to acquire
> read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
>
> Since PID hashing and do_each_pid_task() traversals are already
> RCU-protected, the read_lock on tasklist_lock is no longer strictly
> required for safe traversal. Fix this by replacing tasklist_lock with
> rcu_read_lock(), aligning the process group signaling path with the
> single-PID path.
>
> Lockdep splat:
> =====================================================
> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
> [...]
> Chain exists of:
> &dev->event_lock --> &f_owner->lock --> tasklist_lock
>
> Possible interrupt unsafe locking scenario:
> CPU0 CPU1
> ---- ----
> lock(tasklist_lock);
> local_irq_disable();
> lock(&dev->event_lock);
> lock(&f_owner->lock);
> <Interrupt>
> lock(&dev->event_lock);
>
> *** DEADLOCK ***
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> ---
> fs/fcntl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index beab8080badf..a6c764ede282 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -929,11 +929,11 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
> send_sigio_to_task(p, fown, fd, band, type);
> rcu_read_unlock();
> } else {
> - read_lock(&tasklist_lock);
> + rcu_read_lock();
> do_each_pid_task(pid, type, p) {
> send_sigio_to_task(p, fown, fd, band, type);
> } while_each_pid_task(pid, type, p);
> - read_unlock(&tasklist_lock);
> + rcu_read_unlock();
> }
> out_unlock_fown:
> read_unlock_irqrestore(&fown->lock, flags);
This looks good to me. Sashiko seems to think that send_sigurg has the
same problem though. Care to look into fixing that one too?
https://sashiko.dev/#/patchset/20260523080255.585201-1-w15303746062%40163.com
You can add:
Reviewed-by: Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-05-23 11:08 ` Jeff Layton
@ 2026-05-23 13:52 ` w15303746062
2026-05-28 12:40 ` Christian Brauner
2026-10-04 11:31 ` Oleg Nesterov
0 siblings, 2 replies; 13+ messages in thread
From: w15303746062 @ 2026-05-23 13:52 UTC (permalink / raw)
To: jlayton, chuck.lever, viro, brauner
Cc: alex.aring, jack, linux-fsdevel, linux-kernel, Mingyu Wang
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both
functions use read_lock(&tasklist_lock) to traverse the task list.
However, they are frequently called from softirq context:
- send_sigio() via input_inject_event -> kill_fasync
- send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism:
1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
fork() or exit() and spins, which blocks all new readers.
3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
4. The softirq calls send_sigurg() and attempts to acquire
read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already
RCU-protected, the read_lock on tasklist_lock is no longer strictly
required for safe traversal. Fix this by replacing tasklist_lock with
rcu_read_lock(), aligning the process group signaling path with the
single-PID path. This also mitigates a potential remote denial of
service vector via TCP URG packets.
Lockdep splat:
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
[...]
Chain exists of:
&dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&f_owner->lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK ***
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
Changes in v2:
- Also apply the RCU replacement to send_sigurg() to fix an identical
deadlock vector triggered by TCP URG packets.
- Add Reviewed-by tag from Jeff Layton.
fs/fcntl.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index beab8080badf..92d643a14196 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -929,11 +929,11 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
send_sigio_to_task(p, fown, fd, band, type);
rcu_read_unlock();
} else {
- read_lock(&tasklist_lock);
+ rcu_read_lock();
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, type);
} while_each_pid_task(pid, type, p);
- read_unlock(&tasklist_lock);
+ rcu_read_unlock();
}
out_unlock_fown:
read_unlock_irqrestore(&fown->lock, flags);
@@ -975,11 +975,11 @@ int send_sigurg(struct file *file)
send_sigurg_to_task(p, fown, type);
rcu_read_unlock();
} else {
- read_lock(&tasklist_lock);
+ rcu_read_lock();
do_each_pid_task(pid, type, p) {
send_sigurg_to_task(p, fown, type);
} while_each_pid_task(pid, type, p);
- read_unlock(&tasklist_lock);
+ rcu_read_unlock();
}
out_unlock_fown:
read_unlock_irqrestore(&fown->lock, flags);
--
2.34.1
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-05-23 13:52 ` [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling w15303746062
@ 2026-05-28 12:40 ` Christian Brauner
2026-10-04 11:31 ` Oleg Nesterov
1 sibling, 0 replies; 13+ messages in thread
From: Christian Brauner @ 2026-05-28 12:40 UTC (permalink / raw)
To: w15303746062
Cc: Christian Brauner, jlayton, chuck.lever, viro, alex.aring, jack,
linux-fsdevel, linux-kernel, Mingyu Wang
On Sat, 23 May 2026 21:52:10 +0800, w15303746062@163.com wrote:
> A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
> send_sigio() and send_sigurg() when a process group receives a signal.
>
> When FASYNC is configured for a process group (PIDTYPE_PGID), both
> functions use read_lock(&tasklist_lock) to traverse the task list.
> However, they are frequently called from softirq context:
> - send_sigio() via input_inject_event -> kill_fasync
> - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
>
> [...]
Applied to the vfs-7.2.misc branch of the vfs/vfs.git tree.
Patches in the vfs-7.2.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.2.misc
[1/1] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
https://git.kernel.org/vfs/vfs/c/00633c468382
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-05-23 13:52 ` [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling w15303746062
2026-05-28 12:40 ` Christian Brauner
@ 2026-10-04 11:31 ` Oleg Nesterov
2026-10-11 15:57 ` Oleg Nesterov
1 sibling, 1 reply; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-04 11:31 UTC (permalink / raw)
To: w15303746062, David Laight
Cc: jlayton, chuck.lever, viro, brauner, alex.aring, jack,
linux-fsdevel, linux-kernel, Mingyu Wang
Hi,
On 05/23, w15303746062@163.com wrote:
>
> Since PID hashing and do_each_pid_task() traversals are already
> RCU-protected, the read_lock on tasklist_lock is no longer strictly
> required for safe traversal. Fix this by replacing tasklist_lock with
> rcu_read_lock(),
I don't think we can simply avoid tasklist_lock. Let me quote my old email,
do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
which moves the task from one hlist to another. Yes, it is safe in
that task_struct can't go away. But still this is not right because
do_each_pid_task() can scan the wrong (2nd) hlist.
And... I need to recheck, but perhaps signal_struct->multiprocess logic
is another reason why the lockless do_each_pid_task() is wrong...
See also the recent discussion
https://lore.kernel.org/all/20261003182224.2171b574@pumpkin/
Oleg.
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -929,11 +929,11 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
> send_sigio_to_task(p, fown, fd, band, type);
> rcu_read_unlock();
> } else {
> - read_lock(&tasklist_lock);
> + rcu_read_lock();
> do_each_pid_task(pid, type, p) {
> send_sigio_to_task(p, fown, fd, band, type);
> } while_each_pid_task(pid, type, p);
> - read_unlock(&tasklist_lock);
> + rcu_read_unlock();
> }
> out_unlock_fown:
> read_unlock_irqrestore(&fown->lock, flags);
> @@ -975,11 +975,11 @@ int send_sigurg(struct file *file)
> send_sigurg_to_task(p, fown, type);
> rcu_read_unlock();
> } else {
> - read_lock(&tasklist_lock);
> + rcu_read_lock();
> do_each_pid_task(pid, type, p) {
> send_sigurg_to_task(p, fown, type);
> } while_each_pid_task(pid, type, p);
> - read_unlock(&tasklist_lock);
> + rcu_read_unlock();
> }
> out_unlock_fown:
> read_unlock_irqrestore(&fown->lock, flags);
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-04 11:31 ` Oleg Nesterov
@ 2026-10-11 15:57 ` Oleg Nesterov
2026-10-12 1:42 ` Mingyu Wang
2026-10-12 11:59 ` Jeff Layton
0 siblings, 2 replies; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-11 15:57 UTC (permalink / raw)
To: w15303746062, David Laight
Cc: jlayton, chuck.lever, viro, brauner, alex.aring, jack,
linux-fsdevel, linux-kernel, Mingyu Wang
Nobody replied ;)
In case it was not clear, I believe the commit 00633c4683828
("fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling")
backported to stable trees is wrong.
Right now the fix is not clear to me, I don't even fully understand
the changelog:
The deadlock is caused by the rwlock writer fairness mechanism:
1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
fork() or exit() and spins, which blocks all new readers.
see below ...
3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
4. The softirq calls send_sigurg() and attempts to acquire
read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
but queued_read_lock_slowpath() does not block the reader if
in_interrupt() == T ?
Mingyu, could you provide more details? How was this problem reported?
So far I only sent the doc patch to explain that we can't simply avoid tasklist:
[PATCH] pid: document that do_each_pid_task() needs tasklist_lock
https://lore.kernel.org/all/asuaU8H_5MbO3-cW@redhat.com/
Oleg.
On 10/04, Oleg Nesterov wrote:
>
> Hi,
>
> On 05/23, w15303746062@163.com wrote:
> >
> > Since PID hashing and do_each_pid_task() traversals are already
> > RCU-protected, the read_lock on tasklist_lock is no longer strictly
> > required for safe traversal. Fix this by replacing tasklist_lock with
> > rcu_read_lock(),
>
> I don't think we can simply avoid tasklist_lock. Let me quote my old email,
>
> do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
> which moves the task from one hlist to another. Yes, it is safe in
> that task_struct can't go away. But still this is not right because
> do_each_pid_task() can scan the wrong (2nd) hlist.
>
> And... I need to recheck, but perhaps signal_struct->multiprocess logic
> is another reason why the lockless do_each_pid_task() is wrong...
>
> See also the recent discussion
> https://lore.kernel.org/all/20261003182224.2171b574@pumpkin/
>
> Oleg.
>
> > --- a/fs/fcntl.c
> > +++ b/fs/fcntl.c
> > @@ -929,11 +929,11 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
> > send_sigio_to_task(p, fown, fd, band, type);
> > rcu_read_unlock();
> > } else {
> > - read_lock(&tasklist_lock);
> > + rcu_read_lock();
> > do_each_pid_task(pid, type, p) {
> > send_sigio_to_task(p, fown, fd, band, type);
> > } while_each_pid_task(pid, type, p);
> > - read_unlock(&tasklist_lock);
> > + rcu_read_unlock();
> > }
> > out_unlock_fown:
> > read_unlock_irqrestore(&fown->lock, flags);
> > @@ -975,11 +975,11 @@ int send_sigurg(struct file *file)
> > send_sigurg_to_task(p, fown, type);
> > rcu_read_unlock();
> > } else {
> > - read_lock(&tasklist_lock);
> > + rcu_read_lock();
> > do_each_pid_task(pid, type, p) {
> > send_sigurg_to_task(p, fown, type);
> > } while_each_pid_task(pid, type, p);
> > - read_unlock(&tasklist_lock);
> > + rcu_read_unlock();
> > }
> > out_unlock_fown:
> > read_unlock_irqrestore(&fown->lock, flags);
> > --
> > 2.34.1
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-11 15:57 ` Oleg Nesterov
@ 2026-10-12 1:42 ` Mingyu Wang
2026-10-12 15:39 ` Oleg Nesterov
2026-10-12 11:59 ` Jeff Layton
1 sibling, 1 reply; 13+ messages in thread
From: Mingyu Wang @ 2026-10-12 1:42 UTC (permalink / raw)
To: Oleg Nesterov, w15303746062, David Laight
Cc: jlayton, chuck.lever, viro, brauner, alex.aring, jack,
linux-fsdevel, linux-kernel
Hi Oleg,
Sorry for the delayed response due to the recent holiday break.
> Mingyu, could you provide more details? How was this problem reported?
The warning was found during kernel fuzzing with DevGen, our own testing
tool, in a QEMU x86_64 guest. The report identifies the kernel as
7.0.0 #6, PREEMPT(full).
This was a lockdep report. It does not establish the actual deadlock
interleaving described in my changelog, nor does it substantiate the
claim about a remote denial of service through TCP URG packets.
> but queued_read_lock_slowpath() does not block the reader if
> in_interrupt() == T ?
You are right. My two CPU scenario overlooked that an interrupt reader
can acquire the read lock while the writer is only waiting.
I also agree with your concern about change_pid(PIDTYPE_PGID). RCU
protects the task lifetime, but it does not prevent the traversal from
following a node into another hlist after that node is moved. My
justification for replacing tasklist_lock with RCU was incorrect.
In the original report, the task triggering the warning was in process
context, through a TTY ioctl. Here are the relevant excerpts; omissions
are marked with [...].
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
7.0.0 #6 Tainted: G W N
syz.2.658/3606 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffffffff8760c098 (tasklist_lock){.+.+}-{3:3}, at: send_sigio+0xc0/0x380
fs/fcntl.c:932
and this task is already holding:
ffff888105547220 (&f_owner->lock){....}-{3:3}, at: send_sigio+0x36/0x380
fs/fcntl.c:918
which would create a new lock dependency:
(&f_owner->lock){....}-{3:3} -> (tasklist_lock){.+.+}-{3:3}
[...]
Chain exists of:
&dev->event_lock --> &f_owner->lock --> tasklist_lock
[...]
CPU: 3 UID: 0 PID: 3606 Comm: syz.2.658 Tainted: G W N 7.0.0 #6
PREEMPT(full)
Call Trace:
<TASK>
[...]
send_sigio+0xc0/0x380 fs/fcntl.c:932
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
[...]
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[...]
</TASK>
The report separately records the following lock usage history. These
are historical acquisition paths, not simultaneous CPU stacks showing
a confirmed deadlock.
... which became SOFTIRQ-irq-safe at:
[...]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
led_trigger_event drivers/leds/led-triggers.c:420 [inline]
led_trigger_event+0xdf/0x270 drivers/leds/led-triggers.c:408
kbd_propagate_led_state drivers/tty/vt/keyboard.c:1065 [inline]
kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
handle_softirqs+0x1ba/0x890 kernel/softirq.c:622
[...]
... which became SOFTIRQ-irq-unsafe at:
[...]
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
[...]
The recent program history includes id=658, which contains:
ioctl$TIOCL_PASTESEL(r1, 0x541c, &(0x7f00000000c0))
This is consistent with the reporting stack, but the program history
should not be treated as a validated minimal reproducer.
I support reverting the RCU replacement. I am sharing these excerpts
to clarify how the warning was reported and to help assess the original
warning and determine the appropriate next steps.
Thank you for pointing out these issues.
Mingyu
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-11 15:57 ` Oleg Nesterov
2026-10-12 1:42 ` Mingyu Wang
@ 2026-10-12 11:59 ` Jeff Layton
2026-10-12 15:15 ` Oleg Nesterov
1 sibling, 1 reply; 13+ messages in thread
From: Jeff Layton @ 2026-10-12 11:59 UTC (permalink / raw)
To: Oleg Nesterov, w15303746062, David Laight
Cc: chuck.lever, viro, brauner, alex.aring, jack, linux-fsdevel,
linux-kernel, Mingyu Wang
On Sun, 2026-10-11 at 17:57 +0200, Oleg Nesterov wrote:
> Nobody replied ;)
>
> In case it was not clear, I believe the commit 00633c4683828
> ("fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling")
> backported to stable trees is wrong.
>
> Right now the fix is not clear to me, I don't even fully understand
> the changelog:
>
> The deadlock is caused by the rwlock writer fairness mechanism:
> 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
> 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
> fork() or exit() and spins, which blocks all new readers.
>
> see below ...
>
> 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
> 4. The softirq calls send_sigurg() and attempts to acquire
> read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
>
> but queued_read_lock_slowpath() does not block the reader if
> in_interrupt() == T ?
>
> Mingyu, could you provide more details? How was this problem reported?
>
> So far I only sent the doc patch to explain that we can't simply avoid tasklist:
>
> [PATCH] pid: document that do_each_pid_task() needs tasklist_lock
> https://lore.kernel.org/all/asuaU8H_5MbO3-cW@redhat.com/
>
> Oleg.
>
FYI, I took a closer look, and I think Oleg is correct.
When I reviewed this, I missed the fact that the rcu_read_lock() isn't
sufficient to stabilize the do_each_pid_task() walk. We probably should
revert this patch for now, until the problem and potential solution are
more clear.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-12 11:59 ` Jeff Layton
@ 2026-10-12 15:15 ` Oleg Nesterov
0 siblings, 0 replies; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-12 15:15 UTC (permalink / raw)
To: Jeff Layton
Cc: w15303746062, David Laight, chuck.lever, viro, brauner,
alex.aring, jack, linux-fsdevel, linux-kernel, Mingyu Wang
On 10/12, Jeff Layton wrote:
>
> We probably should
> revert this patch for now, until the problem and potential solution are
> more clear.
Agreed... I'll send the revert for now.
Hmm. The "if (type <= PIDTYPE_TGID)" case in send_sigio/send_sigurg looks
wrong too. send_sigio_to_task() -> ... -> lock_task_sighand() can fail if
we race with de_thread().
Oleg.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-12 1:42 ` Mingyu Wang
@ 2026-10-12 15:39 ` Oleg Nesterov
2026-10-12 16:00 ` Mingyu Wang
0 siblings, 1 reply; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-12 15:39 UTC (permalink / raw)
To: Mingyu Wang
Cc: w15303746062, David Laight, jlayton, chuck.lever, viro, brauner,
alex.aring, jack, linux-fsdevel, linux-kernel
Hi Mingyu,
On 10/12, Mingyu Wang wrote:
>
> In the original report, the task triggering the warning was in process
> context, through a TTY ioctl. Here are the relevant excerpts; omissions
> are marked with [...].
Thanks... so according to lockdep we have the
&dev->event_lock --> &f_owner->lock --> tasklist_lock
chain. At first glance this suggests that kill_fasync()->send_sigio() can
be called under input_dev->event_lock. But I know nothing about drivers/input,
so I can't find who does this...
And,
> input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
...
> kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
> tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
means that ->event_lock can be acquired in softirq context.
That is all I can understand right now. Can you can send the full full
report without omissions? Not that I think this will help, at least to me ;)
Perhaps something like:
read_lock(tasklist) lock(event_lock)
write_lock(tasklist)
<Interrupt>
lock(event_lock) // send_sigio()
// ...
read_lock(tasklist)
Oleg.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-12 15:39 ` Oleg Nesterov
@ 2026-10-12 16:00 ` Mingyu Wang
2026-10-12 16:29 ` Oleg Nesterov
0 siblings, 1 reply; 13+ messages in thread
From: Mingyu Wang @ 2026-10-12 16:00 UTC (permalink / raw)
To: Oleg Nesterov
Cc: w15303746062, David Laight, jlayton, chuck.lever, viro, brauner,
alex.aring, jack, linux-fsdevel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Hi Oleg,
Thanks for taking a look. I have attached the complete reports without
removing any content.
report7.txt corresponds to the warning quoted in my previous reply
(syz.2.658/3606).
report0.txt is another related report (syz.4.14275/37841). In this
report, the reporting task holds dev->event_lock at input_inject_event().
Its current stack includes evdev_ioctl(), input_inject_event(),
evdev_events(), evdev_pass_values(), __pass_event(), and kill_fasync().
This may help identify the input path calling kill_fasync() under
event_lock.
Thanks,
Mingyu
[-- Attachment #2: report0 --]
[-- Type: text/plain, Size: 32307 bytes --]
audit: type=1400 audit(1779455141.728:71): avc: denied { getattr } for pid=162 comm="systemd-udevd" path="/usr/lib/modules/7.0.0/modules.dep.bin" dev="sda" ino=14431670 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
7.0.0 #6 Tainted: G W N
-----------------------------------------------------
syz.4.14275/37841 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffff888132f817f8 (&new->fa_lock){....}-{3:3}, at: kill_fasync_rcu fs/fcntl.c:1135 [inline]
ffff888132f817f8 (&new->fa_lock){....}-{3:3}, at: kill_fasync fs/fcntl.c:1159 [inline]
ffff888132f817f8 (&new->fa_lock){....}-{3:3}, at: kill_fasync+0x13c/0x520 fs/fcntl.c:1152
and this task is already holding:
ffff88811ca3c028 (&client->buffer_lock){....}-{3:3}, at: spin_lock include/linux/spinlock.h:341 [inline]
ffff88811ca3c028 (&client->buffer_lock){....}-{3:3}, at: evdev_pass_values.part.0+0xfb/0x8f0 drivers/input/evdev.c:261
which would create a new lock dependency:
(&client->buffer_lock){....}-{3:3} -> (&new->fa_lock){....}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(&dev->event_lock){..-.}-{3:3}
... which became SOFTIRQ-irq-safe at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
led_trigger_event drivers/leds/led-triggers.c:420 [inline]
led_trigger_event+0xdf/0x270 drivers/leds/led-triggers.c:408
kbd_propagate_led_state drivers/tty/vt/keyboard.c:1065 [inline]
kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
handle_softirqs+0x1ba/0x890 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xd0/0x100 kernel/softirq.c:723
irq_exit_rcu+0xe/0x20 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x70/0x80 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
arch_local_irq_enable arch/x86/include/asm/paravirt.h:529 [inline]
arch_local_irq_restore arch/x86/include/asm/irqflags.h:159 [inline]
__up_console_sem+0x8f/0xa0 kernel/printk/printk.c:347
__console_unlock kernel/printk/printk.c:2932 [inline]
__console_flush_and_unlock kernel/printk/printk.c:3375 [inline]
console_unlock+0x20b/0x240 kernel/printk/printk.c:3413
class_console_lock_destructor include/linux/console.h:736 [inline]
console_callback+0x182/0x420 drivers/tty/vt/vt.c:3275
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
to a SOFTIRQ-irq-unsafe lock:
(tasklist_lock){.+.+}-{3:3}
... which became SOFTIRQ-irq-unsafe at:
...
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&dev->event_lock --> &client->buffer_lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&client->buffer_lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK ***
7 locks held by syz.4.14275/37841:
#0: ffff888105310118 (&evdev->mutex){+.+.}-{4:4}, at: evdev_ioctl_handler drivers/input/evdev.c:1261 [inline]
#0: ffff888105310118 (&evdev->mutex){+.+.}-{4:4}, at: evdev_ioctl+0x84/0x1b0 drivers/input/evdev.c:1279
#1: ffff888105306230 (&dev->event_lock){..-.}-{3:3}, at: class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
#1: ffff888105306230 (&dev->event_lock){..-.}-{3:3}, at: input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
#2: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#2: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#2: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: class_rcu_constructor include/linux/rcupdate.h:1193 [inline]
#2: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: input_inject_event+0xc0/0x3b0 drivers/input/input.c:420
#3: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#3: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#3: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: class_rcu_constructor include/linux/rcupdate.h:1193 [inline]
#3: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: input_pass_values+0x85/0x860 drivers/input/input.c:119
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: evdev_events+0x85/0x440 drivers/input/evdev.c:298
#5: ffff88811ca3c028 (&client->buffer_lock){....}-{3:3}, at: spin_lock include/linux/spinlock.h:341 [inline]
#5: ffff88811ca3c028 (&client->buffer_lock){....}-{3:3}, at: evdev_pass_values.part.0+0xfb/0x8f0 drivers/input/evdev.c:261
#6: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#6: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#6: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: kill_fasync fs/fcntl.c:1158 [inline]
#6: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: kill_fasync+0x66/0x520 fs/fcntl.c:1152
the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
-> (&dev->event_lock){..-.}-{3:3} {
IN-SOFTIRQ-W at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
led_trigger_event drivers/leds/led-triggers.c:420 [inline]
led_trigger_event+0xdf/0x270 drivers/leds/led-triggers.c:408
kbd_propagate_led_state drivers/tty/vt/keyboard.c:1065 [inline]
kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
handle_softirqs+0x1ba/0x890 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xd0/0x100 kernel/softirq.c:723
irq_exit_rcu+0xe/0x20 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x70/0x80 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
arch_local_irq_enable arch/x86/include/asm/paravirt.h:529 [inline]
arch_local_irq_restore arch/x86/include/asm/irqflags.h:159 [inline]
__up_console_sem+0x8f/0xa0 kernel/printk/printk.c:347
__console_unlock kernel/printk/printk.c:2932 [inline]
__console_flush_and_unlock kernel/printk/printk.c:3375 [inline]
console_unlock+0x20b/0x240 kernel/printk/printk.c:3413
class_console_lock_destructor include/linux/console.h:736 [inline]
console_callback+0x182/0x420 drivers/tty/vt/vt.c:3275
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
kbd_led_trigger_activate+0xd2/0x110 drivers/tty/vt/keyboard.c:1021
led_trigger_set+0x4ce/0xaa0 drivers/leds/led-triggers.c:220
led_match_default_trigger drivers/leds/led-triggers.c:277 [inline]
led_match_default_trigger drivers/leds/led-triggers.c:271 [inline]
led_trigger_set_default drivers/leds/led-triggers.c:300 [inline]
led_trigger_set_default+0x1ec/0x2e0 drivers/leds/led-triggers.c:284
led_classdev_register_ext+0x61a/0x950 drivers/leds/led-class.c:578
led_classdev_register include/linux/leds.h:274 [inline]
input_leds_connect+0x4b7/0x890 drivers/input/input-leds.c:145
input_attach_handler+0x180/0x260 drivers/input/input.c:994
input_register_device+0x9fc/0x1030 drivers/input/input.c:2378
atkbd_connect+0x5ef/0xa00 drivers/input/keyboard/atkbd.c:1340
serio_connect_driver drivers/input/serio/serio.c:44 [inline]
serio_driver_probe+0x89/0xe0 drivers/input/serio/serio.c:748
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x266/0x850 drivers/base/dd.c:721
__driver_probe_device+0x2c9/0x390 drivers/base/dd.c:863
driver_probe_device+0x53/0x2a0 drivers/base/dd.c:893
__driver_attach drivers/base/dd.c:1287 [inline]
__driver_attach+0x1c1/0x5a0 drivers/base/dd.c:1227
bus_for_each_dev+0x131/0x1c0 drivers/base/bus.c:383
serio_attach_driver drivers/input/serio/serio.c:777 [inline]
serio_handle_event+0x239/0x980 drivers/input/serio/serio.c:214
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff8af51380>] __key.4+0x0/0x40
-> (&client->buffer_lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x30/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:341 [inline]
evdev_handle_get_val+0x75/0x620 drivers/input/evdev.c:898
evdev_do_ioctl+0x100e/0x1980 drivers/input/evdev.c:1161
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8af51580>] __key.93+0x0/0x40
... acquired at:
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x30/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:341 [inline]
evdev_handle_get_val+0x75/0x620 drivers/input/evdev.c:898
evdev_do_ioctl+0x100e/0x1980 drivers/input/evdev.c:1161
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
the dependencies between the lock to be acquired
and SOFTIRQ-irq-unsafe lock:
-> (tasklist_lock){.+.+}-{3:3} {
HARDIRQ-ON-R at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
SOFTIRQ-ON-R at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
copy_process+0x4d90/0x71f0 kernel/fork.c:2369
kernel_clone+0xef/0x840 kernel/fork.c:2653
user_mode_thread+0xcd/0x110 kernel/fork.c:2729
rest_init+0x29/0x290 init/main.c:725
start_kernel+0x40e/0x530 init/main.c:1210
x86_64_start_reservations+0x21/0x40 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0xd9/0xe0 arch/x86/kernel/head64.c:291
common_startup_64+0x12c/0x138
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff8760c098>] tasklist_lock+0x18/0x40
... acquired at:
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
send_sigio+0xc0/0x380 fs/fcntl.c:932
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&f_owner->lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
__f_setown+0x65/0x3c0 fs/fcntl.c:136
f_setown_ex fs/fcntl.c:254 [inline]
do_fcntl+0x48f/0x1510 fs/fcntl.c:520
__do_sys_fcntl fs/fcntl.c:602 [inline]
__se_sys_fcntl fs/fcntl.c:587 [inline]
__x64_sys_fcntl+0x168/0x200 fs/fcntl.c:587
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
send_sigio+0x36/0x380 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8aee42c0>] __key.1+0x0/0x40
... acquired at:
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
send_sigio+0x36/0x380 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&new->fa_lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
fasync_remove_entry+0xb7/0x1e0 fs/fcntl.c:1012
fasync_helper+0xab/0xc0 fs/fcntl.c:1115
__tty_fasync+0x1f4/0x320 drivers/tty/tty_io.c:2219
tty_fasync+0xa6/0xf0 drivers/tty/tty_io.c:2252
__fput+0x950/0xb50 fs/file_table.c:466
task_work_run+0x170/0x260 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x123/0x4f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x572/0x690 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x13c/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8aee4280>] __key.0+0x0/0x40
... acquired at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x13c/0x520 fs/fcntl.c:1152
__pass_event drivers/input/evdev.c:240 [inline]
evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x532/0x1980 drivers/input/evdev.c:1069
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
stack backtrace:
CPU: 3 UID: 0 PID: 37841 Comm: syz.4.14275 Tainted: G W N 7.0.0 #6 PREEMPT(full)
Tainted: [W]=WARN, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xdb/0x140 lib/dump_stack.c:120
print_bad_irq_dependency kernel/locking/lockdep.c:2616 [inline]
check_irq_usage+0x800/0xaa0 kernel/locking/lockdep.c:2857
check_prev_add kernel/locking/lockdep.c:3169 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x147c/0x22e0 kernel/locking/lockdep.c:5237
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x13c/0x520 fs/fcntl.c:1152
__pass_event drivers/input/evdev.c:240 [inline]
evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x532/0x1980 drivers/input/evdev.c:1069
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7efebdaf359d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007efebc536f98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007efebdd85fa0 RCX: 00007efebdaf359d
RDX: 00002000000001c0 RSI: 0000000040084503 RDI: 0000000000000009
RBP: 00007efebdb92b08 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007efebdd86038 R14: 00007efebdd85fa0 R15: 00007efebc517000
</TASK>
EXT4-fs (loop4): unmounting filesystem 00000000-0000-0000-0000-000000000000.
EXT4-fs (loop5): unmounting filesystem 00000000-0000-0000-0000-000000000000.
<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>
SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>
[-- Attachment #3: report7 --]
[-- Type: text/plain, Size: 32179 bytes --]
audit: type=1400 audit(1779456038.245:50): avc: denied { net_admin } for pid=3196 comm="modprobe" capability=12 scontext=system_u:system_r:kmod_t:s0 tcontext=system_u:system_r:kmod_t:s0 tclass=capability permissive=1
bochs-drm 0000:00:01.0: [drm] Unknown color mode 65536; guessing buffer size.
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
7.0.0 #6 Tainted: G W N
-----------------------------------------------------
syz.2.658/3606 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffffffff8760c098 (tasklist_lock){.+.+}-{3:3}, at: send_sigio+0xc0/0x380 fs/fcntl.c:932
and this task is already holding:
ffff888105547220 (&f_owner->lock){....}-{3:3}, at: send_sigio+0x36/0x380 fs/fcntl.c:918
which would create a new lock dependency:
(&f_owner->lock){....}-{3:3} -> (tasklist_lock){.+.+}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(&dev->event_lock){..-.}-{3:3}
... which became SOFTIRQ-irq-safe at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
led_trigger_event drivers/leds/led-triggers.c:420 [inline]
led_trigger_event+0xdf/0x270 drivers/leds/led-triggers.c:408
kbd_propagate_led_state drivers/tty/vt/keyboard.c:1065 [inline]
kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
handle_softirqs+0x1ba/0x890 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xd0/0x100 kernel/softirq.c:723
irq_exit_rcu+0xe/0x20 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x70/0x80 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
arch_local_irq_enable arch/x86/include/asm/paravirt.h:529 [inline]
arch_local_irq_restore arch/x86/include/asm/irqflags.h:159 [inline]
__up_console_sem+0x8f/0xa0 kernel/printk/printk.c:347
__console_unlock kernel/printk/printk.c:2932 [inline]
__console_flush_and_unlock kernel/printk/printk.c:3375 [inline]
console_unlock+0x20b/0x240 kernel/printk/printk.c:3413
class_console_lock_destructor include/linux/console.h:736 [inline]
console_callback+0x182/0x420 drivers/tty/vt/vt.c:3275
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
to a SOFTIRQ-irq-unsafe lock:
(tasklist_lock){.+.+}-{3:3}
... which became SOFTIRQ-irq-unsafe at:
...
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&f_owner->lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK ***
7 locks held by syz.2.658/3606:
#0: ffff888104d040a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x2b/0x90 drivers/tty/tty_ldisc.c:243
#1: ffff888104a7b0b8 (&buf->lock){+.+.}-{4:4}, at: paste_selection+0x185/0x730 drivers/tty/vt/selection.c:412
#2: ffffffff87ba5c48 (vc_sel.lock){+.+.}-{4:4}, at: paste_selection+0x1b1/0x730 drivers/tty/vt/selection.c:415
#3: ffff888104d042e8 (&tty->termios_rwsem){++++}-{4:4}, at: class_rwsem_read_constructor include/linux/rwsem.h:259 [inline]
#3: ffff888104d042e8 (&tty->termios_rwsem){++++}-{4:4}, at: n_tty_receive_buf_common+0x91/0x1770 drivers/tty/n_tty.c:1678
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: kill_fasync fs/fcntl.c:1158 [inline]
#4: ffffffff87806de0 (rcu_read_lock){....}-{1:3}, at: kill_fasync+0x66/0x520 fs/fcntl.c:1152
#5: ffff88811ccf6210 (&new->fa_lock){....}-{3:3}, at: kill_fasync_rcu fs/fcntl.c:1135 [inline]
#5: ffff88811ccf6210 (&new->fa_lock){....}-{3:3}, at: kill_fasync fs/fcntl.c:1159 [inline]
#5: ffff88811ccf6210 (&new->fa_lock){....}-{3:3}, at: kill_fasync+0x13c/0x520 fs/fcntl.c:1152
#6: ffff888105547220 (&f_owner->lock){....}-{3:3}, at: send_sigio+0x36/0x380 fs/fcntl.c:918
the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
-> (&dev->event_lock){..-.}-{3:3} {
IN-SOFTIRQ-W at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
led_trigger_event drivers/leds/led-triggers.c:420 [inline]
led_trigger_event+0xdf/0x270 drivers/leds/led-triggers.c:408
kbd_propagate_led_state drivers/tty/vt/keyboard.c:1065 [inline]
kbd_bh+0x23c/0x310 drivers/tty/vt/keyboard.c:1244
tasklet_action_common+0x25c/0x3d0 kernel/softirq.c:925
handle_softirqs+0x1ba/0x890 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xd0/0x100 kernel/softirq.c:723
irq_exit_rcu+0xe/0x20 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x70/0x80 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
arch_local_irq_enable arch/x86/include/asm/paravirt.h:529 [inline]
arch_local_irq_restore arch/x86/include/asm/irqflags.h:159 [inline]
__up_console_sem+0x8f/0xa0 kernel/printk/printk.c:347
__console_unlock kernel/printk/printk.c:2932 [inline]
__console_flush_and_unlock kernel/printk/printk.c:3375 [inline]
console_unlock+0x20b/0x240 kernel/printk/printk.c:3413
class_console_lock_destructor include/linux/console.h:736 [inline]
console_callback+0x182/0x420 drivers/tty/vt/vt.c:3275
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x4a/0x70 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa4/0x3b0 drivers/input/input.c:419
__led_set_brightness drivers/leds/led-core.c:52 [inline]
led_set_brightness_nopm drivers/leds/led-core.c:335 [inline]
led_set_brightness_nosleep drivers/leds/led-core.c:369 [inline]
led_set_brightness+0x21c/0x2a0 drivers/leds/led-core.c:328
kbd_led_trigger_activate+0xd2/0x110 drivers/tty/vt/keyboard.c:1021
led_trigger_set+0x4ce/0xaa0 drivers/leds/led-triggers.c:220
led_match_default_trigger drivers/leds/led-triggers.c:277 [inline]
led_match_default_trigger drivers/leds/led-triggers.c:271 [inline]
led_trigger_set_default drivers/leds/led-triggers.c:300 [inline]
led_trigger_set_default+0x1ec/0x2e0 drivers/leds/led-triggers.c:284
led_classdev_register_ext+0x61a/0x950 drivers/leds/led-class.c:578
led_classdev_register include/linux/leds.h:274 [inline]
input_leds_connect+0x4b7/0x890 drivers/input/input-leds.c:145
input_attach_handler+0x180/0x260 drivers/input/input.c:994
input_register_device+0x9fc/0x1030 drivers/input/input.c:2378
atkbd_connect+0x5ef/0xa00 drivers/input/keyboard/atkbd.c:1340
serio_connect_driver drivers/input/serio/serio.c:44 [inline]
serio_driver_probe+0x89/0xe0 drivers/input/serio/serio.c:748
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x266/0x850 drivers/base/dd.c:721
__driver_probe_device+0x2c9/0x390 drivers/base/dd.c:863
driver_probe_device+0x53/0x2a0 drivers/base/dd.c:893
__driver_attach drivers/base/dd.c:1287 [inline]
__driver_attach+0x1c1/0x5a0 drivers/base/dd.c:1227
bus_for_each_dev+0x131/0x1c0 drivers/base/bus.c:383
serio_attach_driver drivers/input/serio/serio.c:777 [inline]
serio_handle_event+0x239/0x980 drivers/input/serio/serio.c:214
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff8af51380>] __key.4+0x0/0x40
-> (&client->buffer_lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x30/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:341 [inline]
evdev_pass_values.part.0+0xfb/0x8f0 drivers/input/evdev.c:261
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8af51580>] __key.93+0x0/0x40
... acquired at:
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x30/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:341 [inline]
evdev_pass_values.part.0+0xfb/0x8f0 drivers/input/evdev.c:261
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&new->fa_lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
fasync_remove_entry+0xb7/0x1e0 fs/fcntl.c:1012
fasync_helper+0xab/0xc0 fs/fcntl.c:1115
__tty_fasync+0x1f4/0x320 drivers/tty/tty_io.c:2219
tty_fasync+0xa6/0xf0 drivers/tty/tty_io.c:2252
__fput+0x950/0xb50 fs/file_table.c:466
task_work_run+0x170/0x260 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x123/0x4f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x572/0x690 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x13c/0x520 fs/fcntl.c:1152
__pass_event drivers/input/evdev.c:240 [inline]
evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8aee4280>] __key.0+0x0/0x40
... acquired at:
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x13c/0x520 fs/fcntl.c:1152
__pass_event drivers/input/evdev.c:240 [inline]
evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
input_pass_values+0x70c/0x860 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&f_owner->lock){....}-{3:3} {
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
__f_setown+0x65/0x3c0 fs/fcntl.c:136
__tty_fasync+0x1d1/0x320 drivers/tty/tty_io.c:2237
tty_fasync+0xa6/0xf0 drivers/tty/tty_io.c:2252
ioctl_fioasync fs/ioctl.c:378 [inline]
do_vfs_ioctl+0x9d7/0x1470 fs/ioctl.c:511
__do_sys_ioctl fs/ioctl.c:595 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x11b/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
send_sigio+0x36/0x380 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff8aee42c0>] __key.1+0x0/0x40
... acquired at:
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:236
send_sigio+0x36/0x380 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
the dependencies between the lock to be acquired
and SOFTIRQ-irq-unsafe lock:
-> (tasklist_lock){.+.+}-{3:3} {
HARDIRQ-ON-R at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
SOFTIRQ-ON-R at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INITIAL USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x44/0x60 kernel/locking/spinlock.c:326
copy_process+0x4d90/0x71f0 kernel/fork.c:2369
kernel_clone+0xef/0x840 kernel/fork.c:2653
user_mode_thread+0xcd/0x110 kernel/fork.c:2729
rest_init+0x29/0x290 init/main.c:725
start_kernel+0x40e/0x530 init/main.c:1210
x86_64_start_reservations+0x21/0x40 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0xd9/0xe0 arch/x86/kernel/head64.c:291
common_startup_64+0x12c/0x138
INITIAL READ USE at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
__do_wait+0xfe/0x870 kernel/exit.c:1678
do_wait+0x1d0/0x5a0 kernel/exit.c:1722
kernel_wait+0xa4/0x160 kernel/exit.c:1898
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xfe/0x190 kernel/umh.c:163
process_one_work+0x920/0x1ac0 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x698/0xeb0 kernel/workqueue.c:3452
kthread+0x38a/0x4a0 kernel/kthread.c:436
ret_from_fork+0x690/0xaa0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff8760c098>] tasklist_lock+0x18/0x40
... acquired at:
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
send_sigio+0xc0/0x380 fs/fcntl.c:932
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
stack backtrace:
CPU: 3 UID: 0 PID: 3606 Comm: syz.2.658 Tainted: G W N 7.0.0 #6 PREEMPT(full)
Tainted: [W]=WARN, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xdb/0x140 lib/dump_stack.c:120
print_bad_irq_dependency kernel/locking/lockdep.c:2616 [inline]
check_irq_usage+0x800/0xaa0 kernel/locking/lockdep.c:2857
check_prev_add kernel/locking/lockdep.c:3169 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x147c/0x22e0 kernel/locking/lockdep.c:5237
lock_acquire kernel/locking/lockdep.c:5868 [inline]
lock_acquire+0x197/0x310 kernel/locking/lockdep.c:5825
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x61/0x70 kernel/locking/spinlock.c:228
send_sigio+0xc0/0x380 fs/fcntl.c:932
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync fs/fcntl.c:1159 [inline]
kill_fasync+0x21d/0x520 fs/fcntl.c:1152
__receive_buf drivers/tty/n_tty.c:1632 [inline]
n_tty_receive_buf_common+0x670/0x1770 drivers/tty/n_tty.c:1715
tty_ldisc_receive_buf+0xa8/0x1c0 drivers/tty/tty_buffer.c:387
paste_selection+0x605/0x730 drivers/tty/vt/selection.c:439
tioclinux+0x3d3/0x630 drivers/tty/vt/vt.c:3505
vt_ioctl+0x23ec/0x2ee0 drivers/tty/vt/vt_ioctl.c:753
tty_ioctl+0x717/0x1670 drivers/tty/tty_io.c:2792
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x690 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7054c7359d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f70536b6f98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f7054f05fa0 RCX: 00007f7054c7359d
RDX: 00002000000000c0 RSI: 000000000000541c RDI: 0000000000000005
RBP: 00007f7054d12b08 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7054f06038 R14: 00007f7054f05fa0 R15: 00007f7053697000
</TASK>
syz-executor (310) used greatest stack depth: 24032 bytes left
<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>
SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-12 16:00 ` Mingyu Wang
@ 2026-10-12 16:29 ` Oleg Nesterov
2026-10-12 17:33 ` Oleg Nesterov
0 siblings, 1 reply; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-12 16:29 UTC (permalink / raw)
To: Mingyu Wang
Cc: w15303746062, David Laight, jlayton, chuck.lever, viro, brauner,
alex.aring, jack, linux-fsdevel, linux-kernel
On 10/13, Mingyu Wang wrote:
>
> report7.txt corresponds to the warning quoted in my previous reply
> (syz.2.658/3606).
...
> kill_fasync fs/fcntl.c:1159 [inline]
> kill_fasync+0x13c/0x520 fs/fcntl.c:1152
> __pass_event drivers/input/evdev.c:240 [inline]
> evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
> evdev_pass_values drivers/input/evdev.c:253 [inline]
> evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
> input_pass_values+0x70c/0x860 drivers/input/input.c:128
> input_event_dispose drivers/input/input.c:353 [inline]
> input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
> input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
> evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
> evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
> evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl fs/ioctl.c:583 [inline]
> __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
Thanks. So yes, this is what I suspected...
kill_fasync() is called under dev->event_lock (input_inject_event() abobe)
in process contect.
If another CPU takes the same dev->event_lock in softirq context and we race
with write_lock(tasklist) on yet another CPU, deadlock is indeed possible...
I'll try to take a look, but I can't promise too much ;)
Oleg.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
2026-10-12 16:29 ` Oleg Nesterov
@ 2026-10-12 17:33 ` Oleg Nesterov
0 siblings, 0 replies; 13+ messages in thread
From: Oleg Nesterov @ 2026-10-12 17:33 UTC (permalink / raw)
To: Mingyu Wang
Cc: w15303746062, David Laight, jlayton, chuck.lever, viro, brauner,
alex.aring, jack, linux-fsdevel, linux-kernel
perhaps it is time to add pid->tasks_lock or abuse pid->lock we already
have (we would need to make it irq-safe) but this doesn't look nice...
Oleg.
On 10/12, Oleg Nesterov wrote:
>
> On 10/13, Mingyu Wang wrote:
> >
> > report7.txt corresponds to the warning quoted in my previous reply
> > (syz.2.658/3606).
>
> ...
>
> > kill_fasync fs/fcntl.c:1159 [inline]
> > kill_fasync+0x13c/0x520 fs/fcntl.c:1152
> > __pass_event drivers/input/evdev.c:240 [inline]
> > evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
> > evdev_pass_values drivers/input/evdev.c:253 [inline]
> > evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
> > input_pass_values+0x70c/0x860 drivers/input/input.c:128
> > input_event_dispose drivers/input/input.c:353 [inline]
> > input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
> > input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
> > evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
> > evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
> > evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
> > vfs_ioctl fs/ioctl.c:51 [inline]
> > __do_sys_ioctl fs/ioctl.c:597 [inline]
> > __se_sys_ioctl fs/ioctl.c:583 [inline]
> > __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
>
> Thanks. So yes, this is what I suspected...
>
> kill_fasync() is called under dev->event_lock (input_inject_event() abobe)
> in process contect.
>
> If another CPU takes the same dev->event_lock in softirq context and we race
> with write_lock(tasklist) on yet another CPU, deadlock is indeed possible...
>
> I'll try to take a look, but I can't promise too much ;)
>
> Oleg.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2026-10-12 17:33 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-05-23 8:02 [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio() w15303746062
2026-05-23 11:08 ` Jeff Layton
2026-05-23 13:52 ` [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling w15303746062
2026-05-28 12:40 ` Christian Brauner
2026-10-04 11:31 ` Oleg Nesterov
2026-10-11 15:57 ` Oleg Nesterov
2026-10-12 1:42 ` Mingyu Wang
2026-10-12 15:39 ` Oleg Nesterov
2026-10-12 16:00 ` Mingyu Wang
2026-10-12 16:29 ` Oleg Nesterov
2026-10-12 17:33 ` Oleg Nesterov
2026-10-12 11:59 ` Jeff Layton
2026-10-12 15:15 ` Oleg Nesterov
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®