The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: stable@kernel.org, Daeho Jeong <daehojeong@google.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to avoid potential section-unaligned pinfile
Date: Thu, 2 Jul 2026 14:26:39 +0000	[thread overview]
Message-ID: <akZ1H45tI_Cqm2vR@google.com> (raw)
In-Reply-To: <20260629114918.224537-1-chao@kernel.org>

Hi Chao,

On 06/29, Chao Yu via Linux-f2fs-devel wrote:
> Blocks of pinfile may not aligned to section size due to wrong use
> on pinfile, result in heavy overhead of GC, let avoid this by
> adding additional check condition in f2fs_setattr().
> 
> - truncate -s 8mb pinfile
> : random checkpoint may persist filesize w/ inode
> - fallocate -o 0 -l 8mb pinfile
>  - f2fs_fallocate
>   - f2fs_expand_inode_data
>    - f2fs_allocate_pinning_section
>    - f2fs_map_blocks
>     - f2fs_map_lock
>     - __allocate_data_block
>     - file_need_truncate
>     : w/ FADVISE_TRUNC_BIT, we can expect unaligned mapping can be
>       truncated while open() if f2fs is not umount abnormally
>     - f2fs_map_unlock
>     : following f2fs checkpoint and sudden power-cut
> 
> - mount
> - open pinfile
>  - f2fs_file_open
>   - finish_preallocate_blocks
>    - truncate_setsize
>    : filesize is 8mb
>    - f2fs_truncate
>    : can only truncate block outside filesize, rather than truncating
>      unaligned blocks inside filesize

Have we reproduced this?

> 
> Fixes: f5a53edcf01e ("f2fs: support aligned pinned file")
> Cc: stable@kernel.org
> Cc: Daeho Jeong <daehojeong@google.com>
> Signed-off-by: Chao Yu <chao@kernel.org>
> ---
>  fs/f2fs/file.c | 28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index f4facd409d9b..11cc8d79c235 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1107,17 +1107,23 @@ int f2fs_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
>  			!IS_ALIGNED(attr->ia_size,
>  			F2FS_BLK_TO_BYTES(fi->i_cluster_size)))
>  			return -EINVAL;
> -		/*
> -		 * To prevent scattered pin block generation, we don't allow
> -		 * smaller/equal size unaligned truncation for pinned file.
> -		 * We only support overwrite IO to pinned file, so don't
> -		 * care about larger size truncation.
> -		 */
> -		if (f2fs_is_pinned_file(inode) &&
> -			attr->ia_size <= i_size_read(inode) &&
> -			!IS_ALIGNED(attr->ia_size,
> -			F2FS_BLK_TO_BYTES(CAP_BLKS_PER_SEC(sbi))))
> -			return -EINVAL;
> +
> +		if (f2fs_is_pinned_file(inode)) {
> +			/*
> +			 * It may break section-aligned fallocate recovery
> +			 * mechanism, so do not allow larger size truncation.
> +			 */
> +			if (attr->ia_size > i_size_read(inode))
> +				return -EINVAL;
> +			/*
> +			 * To prevent scattered pin block generation, we don't
> +			 * allow smaller/equal size unaligned truncation for
> +			 * pinned file.
> +			 */
> +			else if (!IS_ALIGNED(attr->ia_size,
> +				F2FS_BLK_TO_BYTES(CAP_BLKS_PER_SEC(sbi))))
> +				return -EINVAL;
> +		}
>  	}
>  
>  	if (is_quota_modification(idmap, inode, attr)) {
> -- 
> 2.49.0
> 
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  parent reply	other threads:[~2026-07-02 14:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 11:49 [PATCH] f2fs: fix to avoid potential section-unaligned pinfile Chao Yu
2026-06-30  8:50 ` [f2fs-dev] " Zhiguo Niu
2026-06-30 11:02   ` Chao Yu
2026-07-01  3:26     ` Zhiguo Niu
2026-07-02 14:26 ` Jaegeuk Kim [this message]
2026-07-03  0:17   ` Chao Yu

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=akZ1H45tI_Cqm2vR@google.com \
    --to=jaegeuk@kernel.org \
    --cc=chao@kernel.org \
    --cc=daehojeong@google.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox