Re: Improve page refcount scalability

[Jaegeuk Kim]

On 10/14, Linus Torvalds wrote:
> On Wed, 14 Oct 2026 at 10:44, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
> >
> > I already have it:
> 
> So that was my thinking too, but I have my notes (from the original
> truncage/hole punch patch) about mapping_exiting() being problematic
> due to f2fs playing games with it.
> 
> Now, that's probably just a f2fs bug waiting to happen independently
> of this. But the path is
> 
> ioctl(F2FS_IOC_START_ATOMIC_REPLACE) ->
>   f2fs_ioc_start_atomic_write() ->
>     truncate_inode_pages_final()
> 
> and that truncate_inode_pages_final() is the problem - it's what sets
> mapping_set_exiting() on a live inode.
> 
> I had this as a note for the original branch, and it became a
> non-issue with the change to the "set PG_rcu_free on hot pages in the
> read path" instead.
> 
> But your change makes it an issue again.
> 
> Now, I think f2fs really is just buggy here. Calling
> truncate_inode_pages_final() on something that is still live
> afterwards is wrong - because it's not "final". As far as I can tell,
> there may still be hundreds of active readers holding that fd open.

F2FS_IOC_START_ATOMIC_REPLACE was supposed to replace a heavy ATOMIC_FILE class
in Android, consisting of 1) creating a backup file, 2) write data to the file, 3)
fsync(), 4) rename(to original one), 5) fsync(dir).

Indeed, it's a bug that user can see zeros between F2FS_IOC_START_ATOMIC_REPLACE
and F2FS_IOC_COMMIT_ATOMIC_WRITE. I think we need to move the truncation path
into the commit phase and use truncate_inode_pages() instead.

> 
> I might be wrong. Adding Jaegeuk to the cc.
> 
>                  Linus