linux-kernel - Re: [PATCH v2] audit: Avoid excessive dput/dget in audit

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: <9e794b81-3a16-4380-a397-5e58dd5fab78@redhat.com>
Date: Thu, 5 Feb 2026 08:59:11 -0500
From: Waiman Long <llong@...hat.com>
To: Al Viro <viro@...iv.linux.org.uk>, Waiman Long <llong@...hat.com>
Cc: Paul Moore <paul@...l-moore.com>, Eric Paris <eparis@...hat.com>,
 Christian Brauner <brauner@...nel.org>, linux-kernel@...r.kernel.org,
 audit@...r.kernel.org, Richard Guy Briggs <rgb@...hat.com>,
 Ricardo Robaina <rrobaina@...hat.com>, Mateusz Guzik <mjguzik@...il.com>
Subject: Re: [PATCH v2] audit: Avoid excessive dput/dget in audit_context
 setup and reset paths

On 2/5/26 12:22 AM, Al Viro wrote:
> On Wed, Feb 04, 2026 at 10:03:33PM -0500, Waiman Long wrote:
>
>> Now I realize that there is indeed a deadlock problem. Scrap that. Now I
>> have a simpler idea that shouldn't have this type of deadlock problem. So
>> what do you think about the sample code below?
> That it's rather bizarre, TBH.  Basically, you are allowing to park
> a number of (identical) references in there instead of dropping them,
> with your 'xrefs' being the count of skipped drops.  get_share either
> clones a reference or uses up one of those skipped drops; put_share parks
> the reference if possible.  And set discards everything not used up...
The basic idea is to have a pool of extra pwd references inside 
fs_struct. When a user needs a reference, it can borrow one, if 
available, with the get call and then return it back later with a put 
call. I envision that the pool can grow to the maximum number of 
outstanding get's that have ever happen. When it is time to let them go, 
we could implement some low level put_many functions to get rid of them 
in one go instead releasing them one-by-one which could take a while if 
the pool grow big. I am not good in naming, so please let me know if you 
have suggestion of what naming convention should be used.
>
> It could be made to work, but... ouch.  It looks like a special-cased
> variant of something fairly generic, with really confusing calling
> conventions.  Let me poke around and see if we have any other candidates
> for something similar; if nothing else, current->fs->root is interesting
> and not just for audit pathologies...
>
> Note, BTW, that there's chroot_fs_refs() to deal with, along with
> free_fs_struct() (at least).  This stuff is encapsulated in
> fs/fs_struct.c and include/linux/fs_struct.h...  Oh, hell.

I have sent a follow up patch with changes made to other part of 
fs_struct.c AFAICS. Of course, I will go over it again when I am making 
an official patch. However, I haven't looked elsewhere outside of 
fs_struct.[ch]. I believe the change should be pretty self-contained. 
Please let me know if there are other places where I should look.

Cheers,
Longman