All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baokun Li <libaokun@linux.alibaba.com>
To: Jan Kara <jack@suse.cz>
Cc: Ted Tso <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, Mikulas Patocka <mpatocka@redhat.com>,
	Zhang Yi <yi.zhang@huawei.com>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	Ritesh Harjani <ritesh.list@gmail.com>,
	stable@vger.kernel.org, libaokun@linux.alibaba.com
Subject: Re: [PATCH] ext4: Fix maximum orphan file size check
Date: Sat, 3 Oct 2026 23:32:01 +0800	[thread overview]
Message-ID: <bb6a03a7-ab53-40e9-b22b-967ac75d1a7b@linux.alibaba.com> (raw)
In-Reply-To: <20261002115040.2783654-2-jack@suse.cz>

On 2026/10/2 19:50, Jan Kara wrote:
> Mikulas reported that e2fsprogs 1.47.4 with 1k fs blocksize by default
> creates orphan file of the size the kernel rejects. This is because that
> version of e2fsprogs creates 2MB file by default regardless of the block
> size and with 1k blocks that's more than the limit of 512 fs blocks.
> Fix the check to make kernel accept any file upto those 2MB regardless
> of the number of blocks.
>
> Fixes: 7c11c56eb32e ("ext4: align max orphan file size with e2fsprogs limit")
> CC: stable@vger.kernel.org
> Reported-by: Mikulas Patocka <mpatocka@redhat.com>
> Link: https://lore.kernel.org/all/e65cdbfe-3ff9-4638-fbd3-4d8f8880966f@redhat.com
> Signed-off-by: Jan Kara <jack@suse.cz>

Thanks for fixing this.

The problem is only triggered by images created with the problematic
e2fsprogs: 1k-block filesystems between 512MiB and 2GiB, and 2k-block
filesystems between 2GiB and 4GiB.

A more thorough fix would be to rebuild the orphan file with tune2fs.
However, some instances may not get the chance to do that. So I think
it's good to keep the kernel compatible with both versions of
e2fsprogs. Feel free to add:

Reviewed-by: Baokun Li <libaokun@linux.alibaba.com>

> ---
>  fs/ext4/orphan.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/orphan.c b/fs/ext4/orphan.c
> index b4675aa7ea96..7394d04e0fd9 100644
> --- a/fs/ext4/orphan.c
> +++ b/fs/ext4/orphan.c
> @@ -576,6 +576,7 @@ int ext4_init_orphan_info(struct super_block *sb)
>  	int inodes_per_ob = ext4_inodes_per_orphan_block(sb);
>  	struct ext4_orphan_block_tail *ot;
>  	ino_t orphan_ino = le32_to_cpu(EXT4_SB(sb)->s_es->s_orphan_file_inum);
> +	loff_t max_size;
>  
>  	if (!ext4_has_feature_orphan_file(sb))
>  		return 0;
> @@ -589,8 +590,13 @@ int ext4_init_orphan_info(struct super_block *sb)
>  	 * This is just an artificial limit to prevent corrupted fs from
>  	 * consuming absurd amounts of memory when pinning blocks of orphan
>  	 * file in memory.
> +	 *
> +	 * e2fsprogs 1.47.4 produces 2MB orphan files by default regardless
> +	 * of the number of blocks so that's where the second limit comes from.
>  	 */
> -	if (inode->i_size > (EXT4_MAX_ORPHAN_FILE_BLOCKS << inode->i_blkbits)) {
> +	max_size = max(EXT4_MAX_ORPHAN_FILE_BLOCKS << inode->i_blkbits,
> +		       2 << 20);
> +	if (inode->i_size > max_size) {
>  		ext4_msg(sb, KERN_ERR, "orphan file too big: %llu",
>  			 (unsigned long long)inode->i_size);
>  		ret = -EFSCORRUPTED;



  parent reply	other threads:[~2026-10-03 15:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 11:50 [PATCH] ext4: Fix maximum orphan file size check Jan Kara
2026-10-02 11:57 ` sashiko-bot
2026-10-02 12:15 ` Mikulas Patocka
2026-10-03 15:32 ` Baokun Li [this message]
2026-10-08  2:47 ` Zhang Yi

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=bb6a03a7-ab53-40e9-b22b-967ac75d1a7b@linux.alibaba.com \
    --to=libaokun@linux.alibaba.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.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 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.