linux-ext4 - Re: [PATCH 06/50] fs: hold an i_obj_count reference in writeback_sb

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250822-umarmen-mehltau-515d545eadd0@brauner>
Date: Fri, 22 Aug 2025 14:20:58 +0200
From: Christian Brauner <brauner@...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, 
	viro@...iv.linux.org.uk
Subject: Re: [PATCH 06/50] fs: hold an i_obj_count reference in
 writeback_sb_inodes

On Thu, Aug 21, 2025 at 04:18:17PM -0400, Josef Bacik wrote:
> We drop the wb list_lock while writing back inodes, and we could
> manipulate the i_io_list while this is happening and drop our reference
> for the inode. Protect this by holding the i_obj_count reference during
> the writeback.
> 
> Signed-off-by: Josef Bacik <josef@...icpanda.com>
> ---
>  fs/fs-writeback.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 24fccb299de4..2b0d26a58a5a 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -1977,6 +1977,7 @@ static long writeback_sb_inodes(struct super_block *sb,
>  			trace_writeback_sb_inodes_requeue(inode);
>  			continue;
>  		}
> +		iobj_get(inode);
>  		spin_unlock(&wb->list_lock);
>  
>  		/*
> @@ -1987,6 +1988,7 @@ static long writeback_sb_inodes(struct super_block *sb,
>  		if (inode->i_state & I_SYNC) {
>  			/* Wait for I_SYNC. This function drops i_lock... */
>  			inode_sleep_on_writeback(inode);
> +			iobj_put(inode);
>  			/* Inode may be gone, start again */
>  			spin_lock(&wb->list_lock);
>  			continue;
> @@ -2035,10 +2037,9 @@ static long writeback_sb_inodes(struct super_block *sb,
>  		inode_sync_complete(inode);
>  		spin_unlock(&inode->i_lock);
>  
> -		if (unlikely(tmp_wb != wb)) {
> -			spin_unlock(&tmp_wb->list_lock);
> -			spin_lock(&wb->list_lock);
> -		}
> +		spin_unlock(&tmp_wb->list_lock);
> +		iobj_put(inode);
> +		spin_lock(&wb->list_lock);

So if tmp_wb == wb then you unlock and immediately relock dropping the
reference in between and if tmp_wb != wb then you unlock tmp_wb and the
context implies that @wb became unlocked and can be relocked again.
Seems sane, thanks. More contention on @wb->list_lock. I have no
intuition how bad that is and I know you mentioned it in your cover
letter. If it matters then I suspect the reference count would matter as
well. But let's not worry about it yet.