linux-kernel - Re: [RFC PATCH] fanotify: wake-up all waiters on release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ccdghhd5ldpqc3nps5dur5ceqa2dgbteux2y6qddvlfuq3ar4g@m42fp4q5ne7n>
Date: Fri, 23 May 2025 16:18:19 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Jan Kara <jack@...e.cz>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Amir Goldstein <amir73il@...il.com>, Matthew Bobrowski <repnop@...gle.com>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] fanotify: wake-up all waiters on release

On (25/05/21 12:18), Jan Kara wrote:
> On Tue 20-05-25 21:35:12, Sergey Senozhatsky wrote:
> > Once reply response is set for all outstanding requests
> > wake_up_all() of the ->access_waitq waiters so that they
> > can finish user-wait.  Otherwise fsnotify_destroy_group()
> > can wait forever for ->user_waits to reach 0 (which it
> > never will.)
> > 
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@...omium.org>
> 
> We don't use exclusive waits with access_waitq so wake_up() and
> wake_up_all() should do the same thing?

Oh, non-exclusive waiters, I see.  I totally missed that, thanks.

So... the problem is somewhere else then.  I'm currently looking
at some crashes (across all LTS kernels) where group owner just
gets stuck and then hung-task watchdog kicks in and panics the
system.  Basically just a single backtrace in the kernel logs:

 schedule+0x534/0x2540
 fsnotify_destroy_group+0xa7/0x150
 fanotify_release+0x147/0x160
 ____fput+0xe4/0x2a0
 task_work_run+0x71/0xb0
 do_exit+0x1ea/0x800
 do_group_exit+0x81/0x90
 get_signal+0x32d/0x4e0

My assumption was that it's this wait:
	wait_event(group->notification_waitq, !atomic_read(&group->user_waits));

But I guess I was wrong.