Got it.
After acquiring folio lock in mpage_prepare_extent_to_map(), there
is a check to handle the scenario of page getting truncated.
=====================================
folio_lock(folio);
/*
* If the page is no longer dirty, or its mapping no
* longer corresponds to inode we are writing (which
* means it has been truncated or invalidated), or the
* page is already under writeback and we are not doing
* a data integrity writeback, skip the page
*/
if (!folio_test_dirty(folio) ||
(folio_test_writeback(folio) &&
(mpd->wbc->sync_mode == WB_SYNC_NONE)) ||
unlikely(folio->mapping != mapping)) {
folio_unlock(folio);
continue;
}
=====================================
On Tue, Feb 25, 2025 at 4:57 PM RSINGH <rsingh.ind.1272@xxxxxxxxx> wrote:
>
> Hi!
>
> I had the following doubt related to interaction between fallocate(),
> write() and writeback path
> Can someone please provide insights?
>
> In ext4_punch_hole(), writeout of dirty pages is done before acquiring
> inode lock as shown below:
>
> ==========================================
> /*
> * Write out all dirty pages to avoid race conditions
> * Then release them.
> */
> if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
> ret = filemap_write_and_wait_range(mapping, offset,
> offset + length - 1);
> if (ret)
> return ret;
> }
>
> inode_lock(inode);
> ==========================================
>
> Isn't there a chance that after writing dirty pages and before
> acquiring inode lock, more pages can get dirtied while writeback path
> is also processing the dirty pages?
>
> Regards,
> RS
