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

[Stefan Roesch <shr@fb.com>]

On 5/16/22 4:58 PM, Matthew Wilcox wrote:
> 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.

The next version of the patch series will remove the 
	if (!iop && nr_blocks > 1)
check.

> 
> 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
>>
>>