Re: [GIT PULL] ext2, quota, and udf fixes for 6.6-rc1

[Baokun Li <libaokun1@huawei.com>]

Hello!

On 2023/10/23 20:19, Andy Shevchenko wrote:
> On Sat, Oct 21, 2023 at 09:48:38AM +0800, Baokun Li wrote:
>> On 2023/10/20 23:06, Andy Shevchenko wrote:
>>> On Fri, Oct 20, 2023 at 05:51:59PM +0300, Andy Shevchenko wrote:
>>>> On Thu, Oct 19, 2023 at 11:43:47AM -0700, Linus Torvalds wrote:
> ...
>
>>>> I even rebuilt again with just rebased on top of e64db1c50eb5 and it doesn't
>>>> boot, so we found the culprit that triggers this issue.
>> This patch does not seem to cause this problem. Just like linus said, this
>> patch
>> has only two slight differences from the previous:
>> 1) Change "if (err)" to "if (err < 0)"
>>      In all the implementations of dq_op->write_dquot(), the returned value
>> of err
>>      is not greater than 0. Therefore, this does not cause behavior
>> inconsistency.
>> 2) Adding quota_error()
>>      quota_error() does not seem to cause a boot failure.
>>
>> Also, you mentioned that the root file system is initramfs. If no other file
>> system
>> that supports quota is automatically mounted during startup, it seems that
>> quota
>> does not cause this problem logically.
>>
>> In my opinion, as Josh mentioned, replace the CONFIG_DEBUG_LIST related
>> BUG()/BUG_ON() with WARN_ON(), and then check whether the system can be
>> started normally. If yes, it indicates that the panic is caused by the list
>> corruption, then, check for the items that may damage the list. If WARN_ON()
>> is recorded in the dmesg log of the machine after the startup, it is easier
>> to locate the problem.
> I mentioned that I have checked that, but okay, lemme double check it.
> I took the test-mrfld-jr branch and applied that patch on top.
> And as expected no luck.
By "okay" do you mean that after replacing BUG()/BUG_ON() with WARN_ON()
you can boot up normally but don't see any prints, or does the 
replacement have
no effect and still fails to boot up?
> fstab I have, btw is this
>
> $ cat output/target/etc/fstab
> # <file system> <mount pt>      <type>  <options>       <dump>  <pass>
> /dev/root       /               ext2    rw,noauto       0       1
> proc            /proc           proc    defaults        0       0
> devpts          /dev/pts        devpts  defaults,gid=5,mode=620,ptmxmode=0666   0       0
> tmpfs           /dev/shm        tmpfs   mode=0777       0       0
> tmpfs           /tmp            tmpfs   mode=1777       0       0
> tmpfs           /run            tmpfs   mode=0755,nosuid,nodev  0       0
> sysfs           /sys            sysfs   defaults        0       0
>
> Not sure if /dev/root affects this all, it's Buildroot + Busybox in initramfs
> at the end.
>
> On the booted machine
> (clang build of my main branch, based on the latest -rcX):
>
> Welcome to Buildroot
> buildroot login: root
>
> # uname -a
> Linux buildroot 6.6.0-rc7-00142-g9266a02ba229 #28 SMP PREEMPT_DYNAMIC Mon Oct 23 15:00:17 EEST 2023 x86_64 GNU/Linux
>
> # mount
> rootfs on / type rootfs (rw,size=453412k,nr_inodes=113353)
> devtmpfs on /dev type devtmpfs (rw,relatime,size=453412k,nr_inodes=113353,mode=755)
> proc on /proc type proc (rw,relatime)
> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
> tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
> tmpfs on /tmp type tmpfs (rw,relatime)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
> sysfs on /sys type sysfs (rw,relatime)
>
> What is fishy here is the size of rootfs, it's only 30M compressed side,
> I can't be ~450M decompressed. I just noticed this, dunno if it's related.
>
Of the filesystems mounted above, only ext2 (aka rootfs) supports quota,
but it doesn't appear to have quota enabled.
If the quota change is causing ext2 to fail to load the root directory,
you can now do the following checks:

1) Compare the binary generated by ext2  before and after the quota patch.
2) `dumpe2fs -h /dev/root` to see if there are any useful error messages
saved on disk superblock.

Thanks!
-- 
With Best Regards,
Baokun Li
.