From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C50043F482E for ; Mon, 6 Jul 2026 07:26:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783322783; cv=none; b=lNvCZY7+oPYQTJZtkgXlcF+vjN6ZMFPhLaMmcicA7hwY2uRc+Jf35x5+Tsg8JA5j37e+meuKGfOWDO+Q3jA3K4l7CDiMzAp7JiI8OzTeW5FyfDmJA/1TSAeNm4Zta40ceLZB1rD6wsAsHgb6unzsrHoASKpJlpZgmvAkIlhgP74= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783322783; c=relaxed/simple; bh=AQawY+Byau/PxgOOc+pdfEcjzcPgKIGS5PJffps5peA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=OrSzypm/B9YZZoUfSPT2tgl6E8mgbGJVlqyuVwFSjJ0EjUBNS4pzX2ogU8m5fLWZcarQ5mIVXMbL+cP1DaM1oLucXg44VOW2WQUSjBEDd72VTkqHIj73tiieVrMSskcmDEXpoTcnxQ/QnpHkpGMTVxGzyt2fD1B72alXmbEBeOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DdGjD1Gm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DdGjD1Gm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5D421F000E9; Mon, 6 Jul 2026 07:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783322774; bh=r9rr12uEz4wcmEe34JFodnc/izFEa7CRhf+laB57WvU=; h=From:To:Cc:Subject:Date; b=DdGjD1GmWxlQbhI1z0EnFT5ajuIt1SSVXZGcvF9auziq8Li2gC3DMuvwRP2Flc/ky AbvLo/tHeesYET8tmF/jIj7MITuwI+GcsLB4dXS6mUfOMOqH8IgHmxLsDu0UHg8hgd 9YH1TYbctwXE7SyLncPBA/2sWaJJpHELTBEaUBB5fnPGTzntZ5x8myNjDfbiK0wXUd yeiTsIA5X49TUdDj56kwZQlvn+vtf+o50nN6R1DcWWrsJBuFHvPwAvUHT41XxabgP+ /4tGKN9/2SJVC5ZNKqmk0D1c9Jh4rCWQO9aTOgglPAlpicc1ABMpVEZtqao2z4Eg2H +QThLwYCf12KQ== From: Chao Yu To: jaegeuk@kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chao Yu , stable@kernel.org Subject: [PATCH] f2fs: fix to zero post-EOF data when extending file size Date: Mon, 6 Jul 2026 07:26:06 +0000 Message-ID: <20260706072606.3709384-1-chao@kernel.org> X-Mailer: git-send-email 2.55.0.795.g602f6c329a-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 @@ -1,4 +1,16 @@ QA output created by 794 append_write +FAIL: non-zero data in gap [4080,4096) after shutdown+remount +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< +* +001000 truncate_up ... (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, meanwhile, tagging the inode with FI_ZERO_POST_EOF, so that following checkpoint() and fsync() can persist the page contain zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option. Cc: stable@kernel.org Signed-off-by: Chao Yu --- fs/f2fs/checkpoint.c | 4 ++++ fs/f2fs/f2fs.h | 1 + fs/f2fs/file.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 37 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index 064f5b537423..6f486d3a94c7 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -1359,6 +1359,10 @@ static int f2fs_sync_inode_meta(struct f2fs_sb_info *sbi) inode = igrab(&fi->vfs_inode); spin_unlock(&sbi->inode_lock[DIRTY_META]); if (inode) { + if (is_inode_flag_set(inode, FI_ZERO_POST_EOF)) { + filemap_write_and_wait(inode->i_mapping); + clear_inode_flag(inode, FI_ZERO_POST_EOF); + } sync_inode_metadata(inode, 0); /* it's on eviction */ diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 8e2fb0bda467..41be09dad43c 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -939,6 +939,7 @@ enum { FI_ATOMIC_REPLACE, /* indicate atomic replace */ FI_OPENED_FILE, /* indicate file has been opened */ FI_DONATE_FINISHED, /* indicate page donation of file has been finished */ + FI_ZERO_POST_EOF, /* indicate unaligned EOF gap was zeroed in pagecache */ FI_MAX, /* max flag, never be used */ }; diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 11cc8d79c235..2e9d585073ec 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -36,21 +36,43 @@ #include #include +static int fill_zero(struct inode *inode, pgoff_t index, + loff_t start, loff_t len); + static void f2fs_zero_post_eof_page(struct inode *inode, loff_t new_size, bool lock) { loff_t old_size = i_size_read(inode); + unsigned int offset; if (old_size >= new_size) return; - if (mapping_empty(inode->i_mapping)) - return; - if (lock) filemap_invalidate_lock(inode->i_mapping); + /* zero or drop pages only in range of [old_size, new_size] */ truncate_inode_pages_range(inode->i_mapping, old_size, new_size); + + /* + * When expanding an unaligned EOF size, zero post-EOF data in + * pagecache and set FI_ZERO_POST_EOF, so following checkpointing + * or fsync can persist correct data to disk before committing + * inode w/ updated i_size. + */ + if (F2FS_OPTION(F2FS_I_SB(inode)).fsync_mode != FSYNC_MODE_STRICT) + goto out_unlock; + + offset = old_size & (PAGE_SIZE - 1); + if (offset) { + unsigned int len = min_t(loff_t, PAGE_SIZE - offset, + new_size - old_size); + pgoff_t index = old_size >> PAGE_SHIFT; + + fill_zero(inode, index, offset, len); + set_inode_flag(inode, FI_ZERO_POST_EOF); + } +out_unlock: if (lock) filemap_invalidate_unlock(inode->i_mapping); } @@ -304,6 +326,13 @@ static int f2fs_do_sync_file(struct file *file, loff_t start, loff_t end, if (S_ISDIR(inode->i_mode)) goto go_write; + if (is_inode_flag_set(inode, FI_ZERO_POST_EOF)) { + ret = filemap_write_and_wait(inode->i_mapping); + if (ret) + return ret; + clear_inode_flag(inode, FI_ZERO_POST_EOF); + } + /* if fdatasync is triggered, let's do in-place-update */ if (datasync || get_dirty_pages(inode) <= SM_I(sbi)->min_fsync_blocks) set_inode_flag(inode, FI_NEED_IPU); -- 2.49.0