Re: [PATCH v5 4/4] fs: allow lockless ->i_count bumps as long as it does not transition 0->1

[Jan Kara]

On Sat 18-04-26 14:32:42, Mateusz Guzik wrote:
> On Wed, Apr 8, 2026 at 7:01 PM Jan Kara <jack@xxxxxxx> wrote:
> > > +/*
> > > + * igrab_try_lockless - special inode refcount acquire primitive for the inode hash
> > > + * (don't use elsewhere!)
> >
> > Why is this special for inode hash? Because of I_NEW & I_CREATING checks?
> > Then I'd call this function igrab_from_hash() or something like that and
> > integrate there also all the i_state checking and waiting common between
> > find_inode() and find_inode_fast().
> 
> I was looking at deduplicating find_inode stuff and doing other clean
> ups (notably pulling in waiting on I_NEW inodes into it), I don't like
> the idea of making churn changes in this area with this patchset
> though -- the hash code has proven itself to be weirdly eroror-prone,
> so I want to keep everything incremental and submit further rework
> later.

Well, I find this particular suggestion unproblematic since it deduplicates
two places with completely identical code into one. Further refactoring
belongs to a different series I agree. If you still don't want to move
these 10 lines in this series, I can live with that but at least don't call
the function igrab_try_lockless() with the comment "don't use elsewhere".
That just looks silly. Just call it igrab_from_hash() and later we can
move more code into it.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR