Re: [PATCH 4/4] ext4: remove the special buffer dirty handling in do_journal_get_write_access

[Jan Kara <jack@suse.cz>]

On Fri 30-08-24 13:37:39, zhangshida wrote:
> From: Shida Zhang <zhangshida@kylinos.cn>
> 
> This kinda revert the commit 56d35a4cd13e("ext4: Fix dirtying of
> journalled buffers in data=journal mode") made by Jan 14 years ago,
> since the do_get_write_access() itself can deal with the extra
> unexpected buf dirting things in a proper way now.
> 
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Shida Zhang <zhangshida@kylinos.cn>

Looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext4/inode.c | 18 +-----------------
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index a28f279fd02f..2687bf451a25 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -1023,27 +1023,11 @@ static int ext4_dirty_journalled_data(handle_t *handle, struct buffer_head *bh)
>  int do_journal_get_write_access(handle_t *handle, struct inode *inode,
>  				struct buffer_head *bh)
>  {
> -	int dirty = buffer_dirty(bh);
> -	int ret;
> -
>  	if (!buffer_mapped(bh) || buffer_freed(bh))
>  		return 0;
> -	/*
> -	 * ext4_block_write_begin() could have dirtied some buffers. Clean
> -	 * the dirty bit as jbd2_journal_get_write_access() could complain
> -	 * otherwise about fs integrity issues. Setting of the dirty bit
> -	 * by ext4_block_write_begin() isn't a real problem here as we clear
> -	 * the bit before releasing a page lock and thus writeback cannot
> -	 * ever write the buffer.
> -	 */
> -	if (dirty)
> -		clear_buffer_dirty(bh);
>  	BUFFER_TRACE(bh, "get write access");
> -	ret = ext4_journal_get_write_access(handle, inode->i_sb, bh,
> +	return ext4_journal_get_write_access(handle, inode->i_sb, bh,
>  					    EXT4_JTR_NONE);
> -	if (!ret && dirty)
> -		ret = ext4_dirty_journalled_data(handle, bh);
> -	return ret;
>  }
>  
>  int ext4_block_write_begin(handle_t *handle, struct folio *folio,
> -- 
> 2.33.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR