Re: [PATCH v5 07/14] ntfs: update iomap and address space operations

[Christoph Hellwig]

On Sun, Jan 18, 2026 at 02:00:09PM +0900, Namjae Jeon wrote:
> > This function confuses me.  In general end_io handlers should not
> > need to drop a folio reference.  For the normal buffered I/O path,
> > the folio is locked for reads, and has the writeback bit set for
> > writes, so this is no needed.  When doing I/O in a private folio,
> > the caller usually has a reference as it needs to do something with
> > it.  What is the reason for the special pattern here? A somewhat
> > more descriptive name and a comment would help to describe why
> > it's done this way.
> The reason for this pattern is to prevent a race condition between
> metadata I/O and inode eviction (e.g., during umount). ni->folio holds
> mft record blocks (e.g., one 4KB folio containing four 1KB mft
> records). When an MFT record is written to disk via submit_bio(), if a
> concurrent umount occurs, the inode could be evicted, and
> ntfs_evict_big_inode() would call folio_put(ni->folio). If this
> happens before the I/O completes, the folio could be released
> prematurely, potentially leading to data corruption or use-after-free.
> To prevent this, I increment the folio reference count with
> folio_get() before submit_bio() and decrement it in ntfs_bio_end_io().
> I will add the comment for this.

Thanks!

Something else I just noticed:  I think the implementation of the wait
flag in ntfs_dev_write is wrong.  folio_wait_stable only waits for the
writeback bit to be cleared when mapping_stable_writes is set, but even
without that I don't think you can even rely on the writeback bit to be
set at this point.  If the data needs to be on-disk when this function
returns, I'd call filemap_write_and_wait_range for the entire range
after the folio write loop instead.  Or maybe even in the caller
that wants it?