From: Jeff Layton <jlayton@kernel.org>
To: w15303746062@163.com, chuck.lever@oracle.com,
viro@zeniv.linux.org.uk, brauner@kernel.org
Cc: alex.aring@gmail.com, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Mingyu Wang <25181214217@stu.xidian.edu.cn>
Subject: Re: [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio()
Date: Sat, 23 May 2026 07:08:54 -0400 [thread overview]
Message-ID: <d15a25fe784b5d4449c7ce4e56f1428d7ff28885.camel@kernel.org> (raw)
In-Reply-To: <20260523080255.585201-1-w15303746062@163.com>
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>
next prev parent reply other threads:[~2026-05-23 11:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-23 8:02 [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio() w15303746062
2026-05-23 11:08 ` Jeff Layton [this message]
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
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=d15a25fe784b5d4449c7ce4e56f1428d7ff28885.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=25181214217@stu.xidian.edu.cn \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=w15303746062@163.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox