Received-SPF: pass (google.com: domain of linux-kernel+bounces-177640-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sun, 12 May 2024 13:13:58 +0200
From: Jan Kara <jack@suse.cz>
To: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: tytso@mit.edu, jack@suse.com, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/9] jbd2: remove unneeded kmap to do escape in
 jbd2_journal_write_metadata_buffer
Message-ID: <20240512111358.godfwdmyy7ncrfya@quack3>
References: <20240506141801.1165315-1-shikemeng@huaweicloud.com>
 <20240506141801.1165315-6-shikemeng@huaweicloud.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240506141801.1165315-6-shikemeng@huaweicloud.com>

On Mon 06-05-24 22:17:57, Kemeng Shi wrote:
> The data to do escape could be accessed directly from b_frozen_data,
> just remove unneeded kmap.
> 
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>

Ah, good point. But this deserves a comment at that site that jbd2_alloc()
always provides an address from the direct kernel mapping. Otherwise feel
free to add:

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

								Honza

> ---
>  fs/jbd2/journal.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 77fcdc76fdfd..87f558bd2e8a 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -423,11 +423,8 @@ int jbd2_journal_write_metadata_buffer(transaction_t *transaction,
>  	 * Did we need to do an escaping?  Now we've done all the
>  	 * copying, we can finally do so.
>  	 */
> -	if (do_escape) {
> -		mapped_data = kmap_local_folio(new_folio, new_offset);
> -		*((unsigned int *)mapped_data) = 0;
> -		kunmap_local(mapped_data);
> -	}
> +	if (do_escape)
> +		*((unsigned int *)jh_in->b_frozen_data) = 0;
>  
>  	folio_set_bh(new_bh, new_folio, new_offset);
>  	new_bh->b_size = bh_in->b_size;
> -- 
> 2.30.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR