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.