Re: [RFC PATCH v2 03/16] iomap: use iomap_page_create_gfp() in __iomap_write_begin

[Matthew Wilcox <willy@infradead.org>]

On Mon, May 16, 2022 at 09:47:05AM -0700, Stefan Roesch wrote:
> This change uses the new iomap_page_create_gfp() function in the
> function __iomap_write_begin().
> 
> No intended functional changes in this patch.

But there is one.  I don't know if it's harmful or not.

>  	const struct iomap *srcmap = iomap_iter_srcmap(iter);
> -	struct iomap_page *iop = iomap_page_create(iter->inode, folio);
> +	struct iomap_page *iop = to_iomap_page(folio);
>  	loff_t block_size = i_blocksize(iter->inode);
>  	loff_t block_start = round_down(pos, block_size);
>  	loff_t block_end = round_up(pos + len, block_size);
> +	unsigned int nr_blocks = i_blocks_per_folio(iter->inode, folio);
>  	size_t from = offset_in_folio(folio, pos), to = from + len;
>  	size_t poff, plen;
> +	gfp_t  gfp = GFP_NOFS | __GFP_NOFAIL;

For the case where the folio is already uptodate, would need an iop to
be written back (ie nr_blocks > 1) but doesn't have an iop, we used to
create one here, and now we don't.

How much testing has this seen with blocksize < 4k?

>  	if (folio_test_uptodate(folio))
>  		return 0;
>  	folio_clear_error(folio);
>  
> +	if (!iop && nr_blocks > 1)
> +		iop = iomap_page_create_gfp(iter->inode, folio, nr_blocks, gfp);
> +
>  	do {
>  		iomap_adjust_read_range(iter->inode, folio, &block_start,
>  				block_end - block_start, &poff, &plen);
> -- 
> 2.30.2
> 
>