Re: [PATCH RFC v2] btrfs: disable direct reads to avoid dirty folios without fs knowing

[Christian Borntraeger <borntraeger@linux.ibm.com>]

Am 23.07.26 um 13:23 schrieb Filipe Manana:
> On Thu, Jul 23, 2026 at 12:17 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 在 2026/7/23 20:08, Filipe Manana 写道:
>>> On Thu, Jul 23, 2026 at 7:16 AM Qu Wenruo <wqu@suse.com> 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/79b9b1b2-0455-4a7c-85fd-929f4103f198@gmx.com/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.