Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

[Jeff Layton]

On Sun, 2026-10-11 at 17:57 +0200, Oleg Nesterov wrote:
> Nobody replied ;)
> 
> In case it was not clear, I believe the commit 00633c4683828
> ("fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling")
> backported to stable trees is wrong.
> 
> Right now the fix is not clear to me, I don't even fully understand
> the changelog:
> 
>     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.
> 
> see below ...
> 
>     3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
>     4. The softirq calls send_sigurg() and attempts to acquire
>        read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
> 
> but queued_read_lock_slowpath() does not block the reader if
> in_interrupt() == T ?
> 
> Mingyu, could you provide more details? How was this problem reported?
> 
> So far I only sent the doc patch to explain that we can't simply avoid tasklist:
> 
> 	[PATCH] pid: document that do_each_pid_task() needs tasklist_lock
> 	https://lore.kernel.org/all/asuaU8H_5MbO3-cW@xxxxxxxxxx/
> 
> Oleg.
> 

FYI, I took a closer look, and I think Oleg is correct.

When I reviewed this, I missed the fact that the rcu_read_lock() isn't
sufficient to stabilize the do_each_pid_task() walk. We probably should
revert this patch for now, until the problem and potential solution are
more clear.

-- 
Jeff Layton <jlayton@xxxxxxxxxx>