Re: [PATCH/RFC] btrfs: fix folio lock leak in writepage_delalloc() for folios dirtied behind btrfs' back

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

Am 25.07.26 um 08:26 schrieb Boris Burkov:
> On Fri, Jul 24, 2026 at 08:10:36AM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2026/7/23 21:30, Matthew Wilcox 写道:
>>> On Thu, Jul 23, 2026 at 10:12:27AM +0930, Qu Wenruo wrote:
>>>>
>>>>
>>>> 在 2026/7/22 22:27, Matthew Wilcox 写道:
>>>>> On Wed, Jul 22, 2026 at 11:29:36AM +0200, Christian Borntraeger wrote:
>>>>>>     *   4. Thread B loops sync_file_range(WRITE|WAIT) on the target file.
>>>>>>     *      Whenever a full clean cycle (clear_page_dirty_for_io(),
>>>>>>     *      writeback, bits cleared) completes inside thread A's
>>>>>>     *      submission->completion window, the completion-time
>>>>>>     *      set_page_dirty_lock() hits a *clean* folio: filemap_dirty_folio()
>>>>>>     *      sets only the folio flag and the xarray tag - no btrfs subpage
>>>>>>     *      dirty bit, no delalloc reservation.  See the 20-year-old comment
>>>>>>     *      above bio_set_pages_dirty() in block/bio.c describing exactly
>>>>>>     *      this ("other code (eg, flusher threads) could clean the pages").
>>>>>
>>>>> There's your problem.  filemap_dirty_folio() documents that btrfs is
>>>>> doing it wrongly:
>>>>>
>>>>>     * Filesystems which do not use buffer heads should call this function
>>>>>     * from their dirty_folio address space operation.  It ignores the
>>>>>     * contents of folio_get_private(), so if the filesystem marks individual
>>>>>     * blocks as dirty, the filesystem should handle that itself.
>>>>>
>>>>> fs/btrfs/inode.c:       .dirty_folio    = filemap_dirty_folio,
>>>>>
>>>>> so btrfs should have its own btrfs_dirty_folio() which does whatever
>>>>> metadata updates it needs to and then call filemap_dirty_folio() to
>>>>> take care of the page cache business.  See iomap_dirty_folio() as
>>>>> an example, but many other filesystems also do this.
>>>>
>>>> Thanks a lot for the advice.
>>>>
>>>> However it looks like the sub-folio dirty block tracking is a little
>>>> different between iomap and btrfs.
>>>
>>> My point is not that "you should do it the exact same way as iomap".
>>> Rather "the dirty_folio op is the entry point to tell the filesystem
>>> that a folio is being dirtied".
>> And since dirty_folio() is not allowed to sleep, we should introduce some
>> extra mechanism, e.g. page private 2/checked, to notify the fs that the
>> folio is marked dirty without proper preparation.
>>
>> Then during writeback, detect such folio and do needed preparation for it
>> since at writeback we're allowed to sleep.
>>
>> That sounds feasible, but I haven't seen anyone doing that (including the
>> older btrfs cow fixup).
>>
>> Will explore that path. Thanks a lot again for the dirty_folio() help.
>>
>> Thanks,
>> Qu
> 
> Here is my proposal for a candidate fix. It passes the reproducer in
> this thread as well as several more intense reproducers (alluded to but
> not yet included)
> 
> https://lore.kernel.org/linux-btrfs/6758d4f27be0bbdb865cee7dd5adc435c969f4a3.1784960646.git.boris@bur.io/T/#u
I am willing to give it a try, but that does not seem to apply on 7.2-rc4