Re: [PATCH 06/50] fs: hold an i_obj_count reference in writeback_sb_inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
> ---
>  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.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux