linux-ext4 - Re: [PATCH v2 23/54] fs: use refcount_inc_not

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: <20250828220806.GA2077538@google.com>
Date: Thu, 28 Aug 2025 22:08:06 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Josef Bacik <josef@...icpanda.com>
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 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.

- Eric