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
