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 01AAB41A57E for ; Wed, 15 Jul 2026 18:05:22 +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=1784138732; cv=none; b=ubDcU/QfG4zdj/pfGMXiFCritLYGJ58yd/bQYPVbakJ344mQ7lB8wWqWYG+rnCvAO7H9kRRnNbulH3z5+9V+/4H6FF2mP11xXVzpNiIIF5ogT4e/XmFYPYJdojSPGtN0uxBxVS1e78P8fH/6GU41Ter8cEOisfGZj1yeDtaSsRw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784138732; c=relaxed/simple; bh=7pSQjbFXV9qFj+ZKxsdFjMVuwy9mF2AC2gnvRPpsCxQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YvAMsmnzYP9rAZyddjGIEEY2celd7t4zXyjZhZYzEd4qUjkab7N559DmVcpIaZkmQn46UTriFuwYftsrS+awigsG/PJ2E/qLv2fR9wHg2tOpppJQH8hDG8Ob0UIUec37pPec6xCLsxSAYtwSOs9p2moT/WMBXJBYA5lnoEOurtM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mWC4qfOz; 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="mWC4qfOz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30A971F000E9; Wed, 15 Jul 2026 18:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784138719; bh=y+j3XhXAjUTzHooiJRk8qHZv0bycga9dQQh4LFh9mh8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mWC4qfOzaQsOuEZtQEUYBmETZJZEwp1ngTIOTHOrpO2+u1G+f1wODX9qqwMmCN7k3 C02TA/hmNNr5YqA5T21Ga61afs23WkWO/Wnqr66HpRrDI+ynG+Md+Tn/+RaucafaBv lYYD7KVJzEpTYcTt57SCb00Ls7IWeIxxPNR3XVqWIERi2728UpgvZ2SD1mMFwpmnSg z0C0tgrl6vY+jnm8FqEdxkNJW5ehDnfvB2aTQmpYal3hgRVPyiU4ld+UxKsnEUq3/f cXbzWYEKgR3uHe1bI87v6S7dGKmI2M+yF6aP6fNm2TCWua61pyYx1TkBciZPoYVh+8 wkQjtZo+0xtOg== Date: Wed, 15 Jul 2026 18:05:17 +0000 From: Jaegeuk Kim To: Chao Yu Cc: stable@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to zero post-EOF data when extending file size Message-ID: References: <20260706072606.3709384-1-chao@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260706072606.3709384-1-chao@kernel.org> This causes sysmtem hang during xfstests. On 07/06, Chao Yu via Linux-f2fs-devel wrote: > 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 > > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel