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
.
