From: Kiryl Shutsemau <kirill@shutemov.name>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Pedro Falcato <pfalcato@suse.de>, Harry Yoo <harry@kernel.org>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Ilya Gladyshev <ilya.gladyshev@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: Improve page refcount scalability
Date: Fri, 16 Oct 2026 15:43:36 +0100 [thread overview]
Message-ID: <atI30-1q2iEFPEbR@thinkstation> (raw)
In-Reply-To: <atA2g8OgpiNOiVL_@google.com>
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?
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-10-16 14:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 18:43 Improve page refcount scalability Linus Torvalds
2026-10-13 21:03 ` Matthew Wilcox
2026-10-13 21:26 ` Linus Torvalds
2026-10-13 23:20 ` Paul E. McKenney
2026-10-14 10:36 ` Kiryl Shutsemau
2026-10-14 10:46 ` David Hildenbrand (Arm)
2026-10-13 22:43 ` Kiryl Shutsemau
2026-10-13 23:39 ` Linus Torvalds
2026-10-14 11:53 ` Kiryl Shutsemau
2026-10-14 15:28 ` Matthew Wilcox
2026-10-14 0:10 ` Harry Yoo
2026-10-14 1:01 ` Linus Torvalds
2026-10-14 13:59 ` Pedro Falcato
2026-10-14 16:25 ` Linus Torvalds
2026-10-14 16:59 ` Linus Torvalds
2026-10-14 17:15 ` Linus Torvalds
2026-10-14 17:43 ` Kirill A. Shutemov
2026-10-14 18:24 ` Linus Torvalds
2026-10-15 2:12 ` Jaegeuk Kim
2026-10-16 14:43 ` Kiryl Shutsemau [this message]
2026-10-16 15:41 ` Jaegeuk Kim
2026-10-16 14:40 ` Kiryl Shutsemau
2026-10-16 14:47 ` Linus Torvalds
2026-10-16 15:14 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atI30-1q2iEFPEbR@thinkstation \
--to=kirill@shutemov.name \
--cc=david@kernel.org \
--cc=harry@kernel.org \
--cc=ilya.gladyshev@linux.dev \
--cc=jaegeuk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mcgrof@kernel.org \
--cc=paulmck@kernel.org \
--cc=pfalcato@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.