The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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>

  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