Thank you very much for the report.
"jon bird":
> Attempting to do a "ls" of the mount, the console hung and I had to reboot
> it to recover. I've now enabled AUFS_DEBUG in the kernel and tried again.
> This time I triggered a kernel BUG:
If you can, please try enabling these too.
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_BUGVERBOSE=y
> May 07 12:44:54.426410 [39682] sdr kernel: Kernel BUG at c02b1120 [verbose
> debug info unavailable]
> May 07 12:44:54.701095 [39682] sdr kernel: invalid opcode: 0000 [#1]
> PREEMPT SMP
:::
> May 07 12:44:54.701477 [39682] sdr kernel: CPU: 1 PID: 906 Comm: ls Not
> tainted 3.16.57 #6
:::
> May 07 12:44:54.702073 [39682] sdr kernel: EIP is at si_read_lock+0x140/0x170
:::
> May 07 12:44:54.703421 [39682] sdr kernel: Call Trace:
> May 07 12:44:54.703580 [39682] sdr kernel: [<c02b6d10>] ?
> au_xino_do_write+0x20/0x70
> May 07 12:44:54.703718 [39682] sdr kernel: [<c02db2fa>] ?
> au_lgxattr+0x1a/0x180
:::
> May 07 12:44:54.704008 [39682] sdr kernel: [<c02db891>] ?
> aufs_getxattr+0x21/0x30
:::
> May 07 12:44:54.706074 [39682] sdr kernel: [<c01e8ba3>] ?
> SyS_lgetxattr+0x33/0xa0
Unfortunately this Call Trace looks unreliable, and I cannot see the
behaviour exactly. But I can assume that there is a call chain such
like this.
- "ls" issues lgetxattr(2)
+ SyS_lgetxattr()
+ aufs_getxattr()
+ au_lgxattr()
+ si_read_lock()
Currently I totally don't know what is going on.
It might be a known- or unknown-bug in aufs, or there may exist a
problem on other than aufs.
As a first step, I'd suggest you to test single lgetxattr(2) call on a
generic PC (not your embeded target) with the same kernel source and
configuration. If you don't want to write a small test program which
issues lgetxattr(2), then you may use getfattr(1) or some other command.
For your information, there are several bugfixes in aufs3 series after
aufs3.16-20150928 (till the last release of aufs3.19).
3148d7ee 2016-08-18 aufs: possible bugfix, temporary lockdep_off for
debugfs_remove_file
f440be7d 2016-08-13 aufs: possible bugfix, temporary lockdep_off for
debugfs_create_file
b40dbf18 2016-07-27 aufs: bugfix, the positive value from aufs_atomic_open()
e6a1ef58 2016-06-15 aufs: possible bugfix, missing null-test for inode before
refreshing it
ddfbcfbe 2016-06-15 aufs: possible bugfix, debug-print before dput()
a373febe 2016-06-09 aufs: bugfix, half-bad-inode
5e9fdb5b 2016-05-24 aufs: possible bugfix, internal "fsnotify mark" ref-count
2a4ecd7b 2016-05-19 aufs: bugfix, error handling at loading the module
e3fb1354 2016-02-28 aufs: implement new f_op->setfl()
51aba80a 2016-02-21 aufs: bugfix, permission bits under copying-up
c9365751 2016-02-21 aufs: fix an editing failure, EOPNOTSUPP from
vfs_removexattr()
d783b9a5 2016-02-17 aufs: security bugfix, copy-up resets ACL
152ff48b 2016-02-17 aufs: bugfix, set ACL too in copy-up and chmod
9935e9cd 2016-02-17 aufs: bugfix, skipped an unlock for sbinfo
60611249 2016-02-17 Revert "aufs: disable FUSE br temporarily"
aae4cfb3 2016-02-17 aufs: security bugfix, test mnt_ns in open(2) for fuse
branch
9497574d 2016-02-15 aufs: disable FUSE br temporarily
8e80c539 2016-02-07 aufs: bugfix, suppress VFS delayed fput in copy-up
2c9da346 2015-11-10 aufs: bugfix, mvdown and the plink maintenance mode
e024a2b7 2015-11-03 aufs: bugfix, stop NULL param for symbol_put()
9bc3e430 2015-10-30 aufs: possible bugfix, dbrange_test() may fail if UDBA_NONE
0ed3f3fe 2015-10-29 aufs: possible bugfix, stop updating the inode generaion if
AUFS_MVDOWN_KUPPER
023750ae 2015-10-29 aufs: possible bugfix, maintain the internal array if
AUFS_MVDOWN_KUPPER
67dbac45 2015-10-08 aufs: bugfix, whiteout on the deeper branch
They all are not related to your problem, but I am not sure.
Last but not at least, as you might know, aufs3.16 is NOT maintained
anymore. It had stopped since Oct 2015. Additionally I've replaced my
test PC last year. It is intel core5 9th generation. I am afraid
aufs3.16 cannot run on such new machine. Don't expect me that I can
reproduce the problem on my side.
J. R. Okajima
