Re: [PATCH v2 0/7] hfsplus: convert regular file I/O to iomap-based operations

[Matthew Wilcox <willy@infradead.org>]

On Thu, Aug 27, 2026 at 11:35:12AM -0700, Viacheslav Dubeyko wrote:
> On Thu, 2026-08-27 at 01:06 +0100, Matthew Wilcox wrote:
> > On Wed, Aug 26, 2026 at 03:56:07PM -0700, Viacheslav Dubeyko wrote:
> > > Christoph Hellwig has detected that taking the page lock around
> > > the kmap/modify/kunmap section is not enough on its own:
> > > writeback drops the page lock before the write actually completes,
> > > so a mutator that only waits on the lock can still start rewriting
> > > a page whose old contents are still in flight to the device.
> > > Mark the allocation file's mapping with mapping_set_stable_writes()
> > > and call folio_wait_stable() right after taking the page lock in
> > > both functions, so a mutator also waits out any writeback that was
> > > already in progress when it acquired the lock.
> > 
> > Why would you indirect through the stable mechanism rather than just
> > calling folio_wait_writeback() directly?
> 
> The HFS+ allocation file (block bitmap) is represented by sbi-
> >alloc_file inode and mapping represents the block bitmap space. If one
> thread is calling hfsplus_block_allocate() or hfsplus_block_free(),
> then it tries to modify the content of folios/pages in this mapping.
> But writeback could happen in the background in another thread. It
> sounds like "folio's contents to stay unchanged while writeback is in
> progress". This is why folio_wait_stable() was suggested. Do you mean
> that it is not exactly correct approach? Do you think that
> folio_wait_writeback() is better approach?

I haven't looked at this in detail, but folio_wait_stable() is "if the
mapping needs stable pages, thn wait".  You know that you need stable
pages, so you can just call folio_wait_writeback() directly.