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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux