mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baokun Li <libaokun1@huawei.com>
To: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Cc: "Jan Kara" <jack@suse.cz>,
	tytso@mit.edu, stable@vger.kernel.org,
	"Andreas Dilger" <adilger.kernel@dilger.ca>,
	"Stéphane Graber" <stgraber@stgraber.org>,
	"Christian Brauner" <brauner@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	"Wesley Hershberger" <wesley.hershberger@canonical.com>,
	"Yang Erkun" <yangerkun@huawei.com>
Subject: Re: [PATCH 1/1] ext4: fix crash on BUG_ON in ext4_alloc_group_tables
Date: Thu, 26 Sep 2024 22:35:03 +0800	[thread overview]
Message-ID: <9aa773bd-44e8-4e4b-9628-dfbd3bd0a2af@huawei.com> (raw)
In-Reply-To: <CAEivzxcR+yy1HcZSXmRKOuAuGDnwr=EK_G5mRgk4oNxEPMH_=A@mail.gmail.com>

On 2024/9/26 22:19, Aleksandr Mikhalitsyn wrote:
> On Thu, Sep 26, 2024 at 3:58 PM Baokun Li <libaokun1@huawei.com> wrote:
>> On 2024/9/26 19:32, Aleksandr Mikhalitsyn wrote:
>>>>> Question to you and Jan. Do you guys think that it makes sense to try
>>>>> to create a minimal reproducer for this problem without Incus/LXD involved?
>>>>> (only e2fsprogs, lvm tools, etc)
>>>>>
>>>>> I guess this test can be put in the xfstests test suite, right?
>>>>>
>>>>> Kind regards,
>>>>> Alex
>>>> I think it makes sense, and it's good to have more use cases to look
>>>> around some corners. If you have an idea, let it go.
>>> Minimal reproducer:
>>>
>>> mkdir -p /tmp/ext4_crash/mnt
>>> EXT4_CRASH_IMG="/tmp/ext4_crash/disk.img"
>>> rm -f $EXT4_CRASH_IMG
>>> truncate $EXT4_CRASH_IMG --size 25MiB
>>> EXT4_CRASH_DEV=$(losetup --find --nooverlap --direct-io=on --show
>>> $EXT4_CRASH_IMG)
>>> mkfs.ext4 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $EXT4_CRASH_DEV
>>> mount $EXT4_CRASH_DEV /tmp/ext4_crash/mnt
>>> truncate $EXT4_CRASH_IMG --size 3GiB
>>> losetup -c $EXT4_CRASH_DEV
>>> resize2fs $EXT4_CRASH_DEV
>>>
>> Hi Alex,
>>
>> This replicator didn't replicate the issue in my VM, so I took a deeper
>> look. The reproduction of the problem requires the following:
> That's weird. Have just tried once again and it reproduces the issue:
>
> root@ubuntu:/home/ubuntu# mkdir -p /tmp/ext4_crash/mnt
> EXT4_CRASH_IMG="/tmp/ext4_crash/disk.img"
> rm -f $EXT4_CRASH_IMG
> truncate $EXT4_CRASH_IMG --size 25MiB
> EXT4_CRASH_DEV=$(losetup --find --nooverlap --direct-io=on --show
> $EXT4_CRASH_IMG)
> mkfs.ext4 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $EXT4_CRASH_DEV
> mount $EXT4_CRASH_DEV /tmp/ext4_crash/mnt
> truncate $EXT4_CRASH_IMG --size 3GiB
> losetup -c $EXT4_CRASH_DEV
> resize2fs $EXT4_CRASH_DEV
> mke2fs 1.47.0 (5-Feb-2023)
> Creating filesystem with 6400 4k blocks and 6400 inodes
>
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (1024 blocks): done
> Writing superblocks and filesystem accounting information: done
>
> resize2fs 1.47.0 (5-Feb-2023)
> Filesystem at /dev/loop4 is mounted on /tmp/ext4_crash/mnt; on-line
> resizing required
> old_desc_blocks = 1, new_desc_blocks = 1
I can see why, on my side I mkfsed a 25M sized disk, and the ext4
block size is 1024 by default, whereas on your side it's 4096.
I set the block size to 4096 and it also reproduced the issue.

Thanks for your feedback!


Cheers,
Baokun


  reply	other threads:[~2024-09-26 14:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25 14:33 [PATCH 0/1] " Alexander Mikhalitsyn
2024-09-25 14:33 ` [PATCH 1/1] " Alexander Mikhalitsyn
2024-09-25 15:57   ` Jan Kara
2024-09-25 16:17     ` Aleksandr Mikhalitsyn
2024-09-26  8:50       ` Baokun Li
2024-09-26  9:23         ` Aleksandr Mikhalitsyn
2024-09-26  9:40           ` Baokun Li
2024-09-26 11:32             ` Aleksandr Mikhalitsyn
2024-09-26 13:58               ` Baokun Li
2024-09-26 14:19                 ` Aleksandr Mikhalitsyn
2024-09-26 14:35                   ` Baokun Li [this message]
2024-09-26  8:28     ` Baokun Li
2024-09-26  9:16       ` Aleksandr Mikhalitsyn
2024-09-26  9:28         ` Baokun Li
2024-09-26 16:04       ` Eric Sandeen
2024-09-26 16:29         ` Eric Sandeen
2024-09-27  1:51           ` Baokun Li
2024-09-27  2:39             ` Eric Sandeen
2024-09-27  1:43         ` Baokun Li

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=9aa773bd-44e8-4e4b-9628-dfbd3bd0a2af@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=aleksandr.mikhalitsyn@canonical.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stgraber@stgraber.org \
    --cc=tytso@mit.edu \
    --cc=wesley.hershberger@canonical.com \
    --cc=yangerkun@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 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®