From: Oleg Nesterov <oleg@redhat.com>
To: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: w15303746062@163.com, David Laight <david.laight.linux@gmail.com>,
jlayton@kernel.org, chuck.lever@oracle.com,
viro@zeniv.linux.org.uk, brauner@kernel.org,
alex.aring@gmail.com, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
Date: Wed, 14 Oct 2026 14:01:23 +0200 [thread overview]
Message-ID: <as9vE0quEcL3_5Ke@redhat.com> (raw)
In-Reply-To: <94ee706b-f7b7-4d7c-b094-a6fc9b9174b4@stu.xidian.edu.cn>
On 10/13, Mingyu Wang wrote:
>
> Hi Oleg,
>
> In the scenario you described, the tasklist_lock reader holding
> dev->event_lock is in process context. That explains why the
> interrupt-reader handling does not rule out the possible deadlock.
>
>
> > 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...
>
> A fix also needs to preserve the synchronization required for process
> group traversal.
Yes sure. send_sigio() (and other users of do_each_pid_xxx) should take
the new lock instead of tasklist.
OTOH. It would be really nice to not send signals from irq. This will
probably allow to take signal->siglock without disabling irqs. Same for
write_lock(tasklist). So _perhaps_ it makes sense to change send_sigio()
to offload the actual work to workqueues.
But this is the more distant goal, we need something simple for stable.
I am a bit busy right now, will send the patch in a couple of days.
Oleg.
next prev parent reply other threads:[~2026-10-14 12:01 UTC|newest]
Thread overview: 16+ 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
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-14 12:01 ` Oleg Nesterov [this message]
2026-10-14 12:16 ` 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=as9vE0quEcL3_5Ke@redhat.com \
--to=oleg@redhat.com \
--cc=25181214217@stu.xidian.edu.cn \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=david.laight.linux@gmail.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--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.