From: Nanzhe Zhao <nzzhao.sigma@gmail.com>
To: linux-f2fs-devel@lists.sourceforge.net,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>
Cc: Barry Song <baohua@kernel.org>,
Nanzhe Zhao <zhaonanzhe@xiaomi.com>,
Juan Yescas <jyescas@google.com>,
Daeho Jeong <daehojeong@google.com>, Dev Jain <Dev.Jain@arm.com>,
David Hildenbrand <David.Hildenbrand@arm.com>,
linux-kernel@vger.kernel.org, Bo Zhang <zhangbo56@xiaomi.com>,
Kalesh Singh <kaleshsingh@google.com>,
Nanzhe Zhao <nzzhao@126.com>, Pengfei Li <lipengfei28@xiaomi.com>,
Ryan Roberts <Ryan.Roberts@arm.com>
Subject: [PATCH v4 16/18] f2fs: handle block cloning within the same large folio
Date: Tue, 13 Oct 2026 19:56:19 +0800 [thread overview]
Message-ID: <20261013115621.968742-17-nzzhao.sigma@gmail.com> (raw)
In-Reply-To: <20261013115621.968742-1-nzzhao.sigma@gmail.com>
From: Nanzhe Zhao <zhaonanzhe@xiaomi.com>
With large folios, the source and destination block in __clone_blkaddrs()
can belong to the same folio during same-inode operations such as
collapse range and insert range.
In that case, locking the source folio and then looking up the
destination folio can try to lock the same folio again. It also copies
from and to offset 0, which is only correct for order-0 folios.
Detect the same-inode, same-folio case before looking up the destination
folio. Then in this case,we reserve the destination block explicitly.
Signed-off-by: Nanzhe Zhao <zhaonanzhe@xiaomi.com>
---
fs/f2fs/file.c | 61 +++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 53 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 69d1344a5..3c90cd365 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1608,25 +1608,70 @@ static int __clone_blkaddrs(struct inode *src_inode, struct inode *dst_inode,
f2fs_put_dnode(&dn);
} else {
struct folio *fsrc, *fdst;
+ size_t src_off, dst_off;
+ bool same_folio;
fsrc = f2fs_get_lock_data_folio(src_inode,
src + i, true);
if (IS_ERR(fsrc))
return PTR_ERR(fsrc);
- fdst = f2fs_get_new_data_folio(dst_inode, NULL, dst + i,
- true);
- if (IS_ERR(fdst)) {
- f2fs_folio_put(fsrc, true);
- return PTR_ERR(fdst);
+
+ src_off = offset_in_folio(fsrc,
+ (loff_t)(src + i) << PAGE_SHIFT);
+
+ /*
+ * For same-inode operations (collapse/insert), src and
+ * dst may fall within the same large folio. Detect this
+ * to avoid self-deadlock on folio lock.
+ */
+ same_folio = src_inode == dst_inode &&
+ folio_contains(fsrc, dst + i);
+ if (same_folio) {
+ struct dnode_of_data dn;
+
+ /* Reserve block for dst before copying */
+ set_new_dnode(&dn, dst_inode, NULL, NULL, 0);
+ ret = f2fs_reserve_block(&dn, dst + i);
+ if (ret) {
+ f2fs_folio_put(fsrc, true);
+ return ret;
+ }
+ fdst = fsrc;
+ } else {
+ fdst = f2fs_get_new_data_folio(dst_inode, NULL,
+ dst + i, true);
+ if (IS_ERR(fdst)) {
+ f2fs_folio_put(fsrc, true);
+ return PTR_ERR(fdst);
+ }
}
+ dst_off = offset_in_folio(fdst,
+ (loff_t)(dst + i) << PAGE_SHIFT);
f2fs_folio_wait_writeback(fdst, true, true);
-
- memcpy_folio(fdst, 0, fsrc, 0, PAGE_SIZE);
+ memcpy_folio(fdst, dst_off, fsrc, src_off,
+ PAGE_SIZE);
+ if (folio_test_large(fdst)) {
+ if (!f2fs_ffs_find_or_alloc(fdst)) {
+ f2fs_folio_put(fdst, true);
+ if (!same_folio)
+ f2fs_folio_put(fsrc, true);
+ return -ENOMEM;
+ }
+ f2fs_ffs_mark_subrange_uptodate(fdst,
+ dst_off, PAGE_SIZE);
+ f2fs_ffs_mark_subrange_dirty(fdst, dst_off,
+ PAGE_SIZE);
+ }
folio_mark_dirty(fdst);
+ if (same_folio && i_size_read(dst_inode) <
+ ((loff_t)(dst + i + 1) << PAGE_SHIFT))
+ f2fs_i_size_write(dst_inode,
+ ((loff_t)(dst + i + 1) << PAGE_SHIFT));
folio_set_f2fs_gcing(fdst);
f2fs_folio_put(fdst, true);
- f2fs_folio_put(fsrc, true);
+ if (!same_folio)
+ f2fs_folio_put(fsrc, true);
ret = f2fs_truncate_hole(src_inode,
src + i, src + i + 1);
--
2.43.0
next prev parent reply other threads:[~2026-10-13 11:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 11:56 [PATCH v4 00/18] f2fs: support & optimize large folios for writable files Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 01/18] f2fs: read i_size once in f2fs_vm_page_mkwrite Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 02/18] f2fs: remove mappedtodisk flag usage in mmap write path Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 03/18] f2fs: extend folio state for large folio " Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 04/18] f2fs: carry subpage offset and count in write IO Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 05/18] f2fs: support regular file buffered writes on large folios Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 06/18] f2fs: support atomic file large folios buffered write Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 07/18] f2fs: support large folio writeback Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 08/18] f2fs: account large folio dirty data at block granularity Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 09/18] f2fs: prepare mmap write faults for large folios Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 10/18] f2fs: make GC migration large-folio aware Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 11/18] f2fs: optimize small block size large folio read Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 12/18] f2fs: support partial uptodate " Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 13/18] f2fs: handle partial truncate of large folio dirty subpages Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 14/18] f2fs: wait for folio writeback before ffs_detach_free Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 15/18] f2fs: fix zeroing paths for large folios Nanzhe Zhao
2026-10-13 11:56 ` Nanzhe Zhao [this message]
2026-10-13 11:56 ` [PATCH v4 17/18] f2fs: allow large folio support to writeable files Nanzhe Zhao
2026-10-13 11:56 ` [PATCH v4 18/18] f2fs: make compressed files compatible with large folio Nanzhe Zhao
2026-10-13 18:46 ` [f2fs-dev] [PATCH v4 00/18] f2fs: support & optimize large folios for writable files Jaegeuk Kim
2026-10-14 1:08 ` Chao Yu
2026-10-14 1:43 ` Jaegeuk Kim
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=20261013115621.968742-17-nzzhao.sigma@gmail.com \
--to=nzzhao.sigma@gmail.com \
--cc=David.Hildenbrand@arm.com \
--cc=Dev.Jain@arm.com \
--cc=Ryan.Roberts@arm.com \
--cc=baohua@kernel.org \
--cc=chao@kernel.org \
--cc=daehojeong@google.com \
--cc=jaegeuk@kernel.org \
--cc=jyescas@google.com \
--cc=kaleshsingh@google.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lipengfei28@xiaomi.com \
--cc=nzzhao@126.com \
--cc=zhangbo56@xiaomi.com \
--cc=zhaonanzhe@xiaomi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®