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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKYAXd9pYVu7cCLrJ_KWNs2ysJOx75tq5wJTZpDBdr-dvcvazw@mail.gmail.com>
Date: Tue, 20 Jan 2026 13:28:23 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: 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 Mon, Jan 19, 2026 at 4:17 PM Christoph Hellwig <hch@....de> wrote:
>
> 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?
Right. I will call filemap_write_and_wait_range() instead of
folio_wait_stable().
Thanks for your review!