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