All of lore.kernel.org
 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: 14+ 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
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-13  1:36                   ` Mingyu Wang
2026-10-12 11:59         ` Jeff Layton
2026-10-12 15:15           ` Oleg Nesterov

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.