Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
From: Oleg Nesterov
Date: Wed Oct 14 2026 - 08:08:03 EST
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.