[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250829134254.GA2854962@perftesting>
Date: Fri, 29 Aug 2025 09:42:54 -0400
From: Josef Bacik <josef@...icpanda.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
kernel-team@...com, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, brauner@...nel.org,
viro@...iv.linux.org.uk, amir73il@...il.com
Subject: Re: [PATCH v2 23/54] fs: use refcount_inc_not_zero in igrab
On Thu, Aug 28, 2025 at 10:08:06PM +0000, Eric Biggers wrote:
> On Tue, Aug 26, 2025 at 11:39:23AM -0400, Josef Bacik wrote:
> > +static inline struct inode *inode_tryget(struct inode *inode)
> > +{
> > + /*
> > + * We are using inode_tryget() because we're interested in getting a
> > + * live reference to the inode, which is ->i_count. Normally we would
> > + * grab i_obj_count first, as it is the higher priority reference.
> > + * However we're only interested in making sure we have a live inode,
> > + * and we know that if we get a reference for i_count then we can safely
> > + * acquire i_obj_count because we always drop i_obj_count after dropping
> > + * an i_count reference.
> > + *
> > + * This is meant to be used either in a place where we have an existing
> > + * i_obj_count reference on the inode, or under rcu_read_lock() so we
> > + * know we're safe in accessing this inode still.
> > + */
> > + VFS_WARN_ON_ONCE(!iobj_count_read(inode) && !rcu_read_lock_held());
> > +
> > + if (refcount_inc_not_zero(&inode->i_count)) {
> > + iobj_get(inode);
> > + return inode;
> > + }
> > +
> > + /*
> > + * If we failed to increment the reference count, then the
> > + * inode is being freed or has been freed. We return NULL
> > + * in this case.
> > + */
> > + return NULL;
>
> Is there a reason to take one i_obj_count reference per i_count
> reference, instead of a single i_obj_count reference associated with
> i_count being nonzero? With a single reference owned by i_count != 0,
> it wouldn't be necessary to touch i_obj_count when i_count is changed,
> except when i_count reaches zero. That would be more efficient.
>
> BTW, fscrypt_master_key::mk_active_refs and
> fscrypt_master_key::mk_struct_refs use that solution. For
> mk_active_refs != 0, one reference in mk_struct_refs is held.
>
That certainly could be done as well, hell I do that pattern for the writeback
lists and such. I'll discuss with Christian and see what he thinks. Thanks,
Josef
Powered by blists - more mailing lists