Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Feb 04, 2026 at 01:16:15PM -0500, Waiman Long wrote:


> Thanks for the detailed explanation. I am thinking about something like
> the code diff below. Of course, there are other corner cases like unshare(2)
> that still needs to be handled. Do you think something like this is viable?

Deadlocks aside, the immediate problem here is that consensus number is too
low.  Take three threads sharing the same fs_struct instance.  The first one
calls your get_fs_pwd_share(); then the remaining two threads call set_fs_pwd()
(e.g. by calling chdir(2) in userland code).  The reference stored into
fs->pwd_waiter by the first of those two gets overwritten by that stored
by the second.  When the caller of get_fs_pwd_share() gets to put_fs_pwd_share(),
only one of the sleepers gets woken up...

And it's very easy to end up with something as simple as chdir("foo") deadlocking -
we start with resolving the relative pathname we'd been given, audit wants to
record the current directory, on the theory that relative pathname is none too
useful in logs without knowing what had it been relative to.  Then, in the
same thread, you call set_fs_pwd() - after all, that's the main effect of chdir(2).
Deadlock...

IOW, it's not just unshare(2) that needs to be taken care of - chdir(2) would need
to be treated differently.