Re: Improve page refcount scalability

[Jaegeuk Kim]

On 10/16, Kiryl Shutsemau wrote:
> On Thu, Oct 15, 2026 at 02:12:19AM +0000, Jaegeuk Kim wrote:
> > 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.
> 
> What about f2fs_abort_atomic_write(inode, true)?
> 
> It calls truncate_inode_pages_final() as well. As far as I can see, it
> runs on the last writer's close (f2fs_release_file()), on flush when the
> atomic writer exits (f2fs_file_flush()), from
> F2FS_IOC_ABORT_ATOMIC_WRITE and when F2FS_IOC_COMMIT_ATOMIC_WRITE fails.
> 
> Can other processes still have the file open at those points?
> 
> AS_EXITING is never cleared. Does the inode then stay "exiting" until
> it is evicted? If so, reclaim stops leaving shadow entries for the file,
> and with the rcu-free series a hot folio of it could be freed without a
> grace period while a reader still has the file open.
> 
> Would truncate_inode_pages() work for the abort path too?

Yup, we revisited all the cases and the fix is coming.
https://lore.kernel.org/lkml/20261015161714.1586334-1-daeho43@xxxxxxxxx/

Regarding the truncated page access during the transaction, we reached out a
conclusion that the user land provides a synchronization method to prevent it.
So, I think we're fine with the above patch only.

> 
> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov