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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260119071719.GD1480@lst.de>
Date: Mon, 19 Jan 2026 08:17:19 +0100
From: Christoph Hellwig <hch@....de>
To: Namjae Jeon <linkinjeon@...nel.org>
Cc: Christoph Hellwig <hch@....de>, viro@...iv.linux.org.uk,
	brauner@...nel.org, tytso@....edu, willy@...radead.org,
	jack@...e.cz, djwong@...nel.org, josef@...icpanda.com,
	sandeen@...deen.net, rgoldwyn@...e.com, xiang@...nel.org,
	dsterba@...e.com, pali@...nel.org, ebiggers@...nel.org,
	neil@...wn.name, amir73il@...il.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, iamjoonsoo.kim@....com,
	cheol.lee@....com, jay.sim@....com, gunho.lee@....com,
	Hyunchul Lee <hyc.lee@...il.com>
Subject: Re: [PATCH v5 07/14] ntfs: update iomap and address space
 operations

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?