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:

quoted

+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