Re: [PATCH] btrfs: refactor read_key_bytes() to remove the dest_folio parameter

On Mon, Aug 17, 2026 at 05:00:43PM +0930, Qu Wenruo wrote:
> The function read_key_bytes() have 3 call sites:
> 
> - For BTRFS_VERITY_DESC_ITEM_KEY offset 0 inside btrfs_get_verity_descriptor()
> - For BTRFS_VERITY_DESC_ITEM_KEY offset 1 inside btrfs_get_verity_descriptor()
>   Those are to read the description items, which are pretty small with
>   fixed item size.
> 
>   Those call sites do not utilize the @dest_folio parameter.
> 
> - For btrfs_read_merkle_tree_page()
>   This is to read the BTRFS_VERITY_MERKLE_ITEM_KEY, which can be pretty
>   large and split into multiple items.
> 
>   This is the only call site utilizing the @dest_folio parameter.
> 
> Just for the only btrfs_read_merkle_tree_page() call site, we have a
> complex scheme for @dest and @dest_folio parameters.
> Since @dest can be NULL, it means if we pass @dest as NULL, then no
> matter if @dest_folio is provided, the merkle data will not be loaded
> into that @dest_folio.
> 
> This can lead to a bug where a highmem folio is not mapped, then we pass
> folio_address(folio), which is NULL, into read_key_bytes(), causing no
> data to be written into @dest_folio.
> 
> To address the complex scheme between @dest and @dest_folio, remove the
> @dest_folio parameter completely, and let the only caller to map the
> folio and pass the mapped kernel address into read_key_bytes() instead.
> 
> This not only reduces the parameter list, but also make it much clear on
> the @dest parameter handling.
> The only downside is a longer duration of locally mapped page, but this
> should still be fine, as kmap_local_folio() can survive context switch.
> 
> Reported-by: Hongling Zeng <[email protected]>
> Link: https://lore.kernel.org/linux-btrfs/[email protected]/
> Fixes: 146054090b08 ("btrfs: initial fsverity support")
> Signed-off-by: Qu Wenruo <[email protected]>

Reviewed-by: David Sterba <[email protected]>