Re: [PATCH RFC v2] btrfs: disable direct reads to avoid dirty folios without fs knowing
Christian Borntraeger <[email protected]> Thu, 23 Jul 2026 13:45:15 +0200
| Newsgroups | org.kernel.vger.linux-btrfs |
|---|---|
| Message-ID | <[email protected]> |
Am 23.07.26 um 13:23 schrieb Filipe Manana: > On Thu, Jul 23, 2026 at 12:17 PM Qu Wenruo <[email protected]> wrote: >> >> >> >> 在 2026/7/23 20:08, Filipe Manana 写道: >>> On Thu, Jul 23, 2026 at 7:16 AM Qu Wenruo <[email protected]> wrote: >>>> >>>> There is a bug report that a reproducer which doing the following >>>> workloads in two threads: >>>> >>>> - Direct read into memory mapped from page cache >>>> - Sync the above range >>>> >>>> This can lead to dirty folios without fs knowing, this can be a huge >>> >>> Can you please explain where, and why, the folio is dirtied? >> >> >> btrfs_check_read_bio() >> |- __iomap_dio_bio_end_io() from btrfs_bio_end_io() >> |- bio_check_pages_dirty() >> |- bio_dirty_fn() >> |- bio_release_pages(bio, true) >> |- __bio_release_pages(bio, mark_dirty == true) >> |- folio_mark_dirty() >> >> At least this is the one from the reproducer. > > That should be part of the change log, it's not obvious at all. > I also wonder why a direct IO read dirties the folio if it's not > supposed to change file data. > >> See also the initial discussion here https://lore.kernel.org/linux-s390/[email protected]/T/#m31c388aa6bbfb77c689ff95b5a35c4db5fc231c3 In essence any gup+set_page_dirty_lock user can trigger inconsistencies. We found that as this resulted in lockups and the O_DIRECT use case was just a reproducer that does not need a kernel module.