linux-ext4 - Re: [PATCH v2 30/54] fs: change evict_dentries_for_decrypted

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: <20250828222610.GB2077538@google.com>
Date: Thu, 28 Aug 2025 22:26:10 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Josef Bacik <josef@...icpanda.com>, linux-fsdevel@...r.kernel.org,
	linux-btrfs@...r.kernel.org, kernel-team@...com,
	linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
	viro@...iv.linux.org.uk, amir73il@...il.com
Subject: Re: [PATCH v2 30/54] fs: change evict_dentries_for_decrypted_inodes
 to use refcount

On Thu, Aug 28, 2025 at 02:25:21PM +0200, Christian Brauner wrote:
> On Tue, Aug 26, 2025 at 11:39:30AM -0400, Josef Bacik wrote:
> > Instead of checking for I_WILL_FREE|I_FREEING simply use the refcount to
> > make sure we have a live inode.
> > 
> > Signed-off-by: Josef Bacik <josef@...icpanda.com>
> > ---
> I have no idea how the lifetime of such decrypted inodes are managed.
> I suppose they don't carry a separate reference but are still somehow
> safe to be accessed based on the mk_decrypted_inodes list. In any case
> something must hold an i_obj_count if we want to use igrab() since I
> don't see any relevant rcu protection here.
> 

inodes are placed on mk_decrypted_inodes by the filesystem while it's
holding an i_count reference, and they're removed from the list by
->evict_inode shortly after i_count reaches zero.  So the corresponding
i_obj_count reference is just the one associated with i_count.

This patch looks correct: we do igrab() while holding
mk_decrypted_inodes_lock.  So either i_count is nonzero and we get a
temporary i_count reference, or it's zero and we skip the inode since it
cannot have dentries (and ->evict_inode is coming very soon as well).

Reviewed-by: Eric Biggers <ebiggers@...nel.org>

- Eric