linux-ext4 - Re: Doubt about race condition between fallocate() and writeback path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD+278Xkq3WiHWG76u1NzO6NSi5p3O_CEBRpG8GKBny368HsOQ@mail.gmail.com>
Date: Tue, 25 Feb 2025 18:23:03 +0530
From: rsingh <rsingh.ind.1272@...il.com>
To: linux-ext4@...r.kernel.org
Subject: Re: Doubt about race condition between fallocate() and writeback path

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@...il.com> 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