aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

[Mark Millard]

Later I give notes about the context. The failure reported . . .

# panic: ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry
cpuid = 0
time = 1609844528
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
         pc = 0xffff00000081c654  lr = 0xffff00000011ccb4
         sp = 0xffff0000ac7a9e60  fp = 0xffff0000ac7aa060

db_trace_self_wrapper() at vpanic+0x198
         pc = 0xffff00000011ccb4  lr = 0xffff0000004be678
         sp = 0xffff0000ac7aa070  fp = 0xffff0000ac7aa0d0

vpanic() at panic+0x44
         pc = 0xffff0000004be678  lr = 0xffff0000004be4dc
         sp = 0xffff0000ac7aa0e0  fp = 0xffff0000ac7aa190

panic() at ufs_lookup_ino+0xc9c
         pc = 0xffff0000004be4dc  lr = 0xffff000000775044
         sp = 0xffff0000ac7aa1a0  fp = 0xffff0000ac7aa270

ufs_lookup_ino() at vfs_cache_lookup+0xd0
         pc = 0xffff000000775044  lr = 0xffff00000059a768
         sp = 0xffff0000ac7aa280  fp = 0xffff0000ac7aa2f0

vfs_cache_lookup() at cache_fplookup_noentry+0x158
         pc = 0xffff00000059a768  lr = 0xffff00000059f270
         sp = 0xffff0000ac7aa300  fp = 0xffff0000ac7aa340

cache_fplookup_noentry() at cache_fplookup+0x440
         pc = 0xffff00000059f270  lr = 0xffff00000059c0f4
         sp = 0xffff0000ac7aa350  fp = 0xffff0000ac7aa410

cache_fplookup() at namei+0xd0
         pc = 0xffff00000059c0f4  lr = 0xffff0000005a79fc
         sp = 0xffff0000ac7aa420  fp = 0xffff0000ac7aa4f0

namei() at kern_statat+0xa4
         pc = 0xffff0000005a79fc  lr = 0xffff0000005c82d8
         sp = 0xffff0000ac7aa500  fp = 0xffff0000ac7aa660

kern_statat() at sys_fstatat+0x2c
         pc = 0xffff0000005c82d8  lr = 0xffff0000005c888c
         sp = 0xffff0000ac7aa670  fp = 0xffff0000ac7aa780

sys_fstatat() at do_el0_sync+0x460
         pc = 0xffff0000005c888c  lr = 0xffff00000083e048
         sp = 0xffff0000ac7aa790  fp = 0xffff0000ac7aa820

do_el0_sync() at handle_el0_sync+0x90
         pc = 0xffff00000083e048  lr = 0xffff00000081f224
         sp = 0xffff0000ac7aa830  fp = 0xffff0000ac7aa980

handle_el0_sync() at 0x403da3e8
         pc = 0xffff00000081f224  lr = 0x00000000403da3e8
         sp = 0xffff0000ac7aa990  fp = 0x0000ffffffffe630

KDB: enter: panic
[ thread pid 58718 tid 100101 ]
Stopped at      0x403dd330
db> 

Unfortunately the db> prompt is not taking any input so all I have
is the backtrace. The machine had been left idle after upgrading
from being head -r368820 based and other activity. The
"~/fbsd-based-on-what-freebsd-main.sh mm-src" and uname below just
happened to be the last things I did before leaving it idle
overnight. I've no clue how long it was idle before the panic
happened.

# ~/fbsd-based-on-what-freebsd-main.sh mm-src
58661b3ba9ebe82f889cbc336afe618ad7f7940a
CommitDate: 2021-01-04 15:12:03 -0800
085d41abe5f1 58661b3ba9eb (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
# uname -apKU
FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255600-g085d41abe5f1 GENERIC-NODBG  arm64 aarch64 1300133 1300133

I did a fair amount of activity after the upgrade but before leaving
it idle, lots of file system activity being involved.

The machine is a MACCHIATOBin Double Shot. FreeBSD was from a
cross build, using -mcpu=cortex-a72 . (I mention mcpu in part
because I've caught a missing-synchronization issue in the past
from doing this, something a cortex-a53 running the same
build did not show and for which the cortex-a72 did not show
the issue when running a plain aarch64 or cortex-a53 targeted
build. I'm not claiming to know that the wider range of behavior
for the cortex-a72 is involved here.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)