20190306 15:27:47 all (309/617): crossmp10.sh
panic: mutex EXT2FS not owned at ../../../kern/kern_mutex.c:281
cpuid = 9
time = 1551882471
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00bfb3f480
vpanic() at vpanic+0x1b4/frame 0xfffffe00bfb3f4e0
panic() at panic+0x43/frame 0xfffffe00bfb3f540
__mtx_unlock_flags() at __mtx_unlock_flags+0x13a/frame 0xfffffe00bfb3f570
ext2_valloc() at ext2_valloc+0x530/frame 0xfffffe00bfb3f620
ext2_makeinode() at ext2_makeinode+0x56/frame 0xfffffe00bfb3f680
ext2_create() at ext2_create+0x2d/frame 0xfffffe00bfb3f6a0
VOP_CREATE_APV() at VOP_CREATE_APV+0x86/frame 0xfffffe00bfb3f6d0
vn_open_cred() at vn_open_cred+0x2c3/frame 0xfffffe00bfb3f820
kern_openat() at kern_openat+0x1fd/frame 0xfffffe00bfb3f990
amd64_syscall() at amd64_syscall+0x291/frame 0xfffffe00bfb3fab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00bfb3fab0
Details @ https://people.freebsd.org/~pho/stress/log/crossmp10-2.txt
Seems to be introduced by r344752.
Any chance of bisecting this? If we can pinpoint the specific change that needs reverting it would really help.
- r344753 and r344754 added some locks which were not there before so they look as good suspects.
I am started to work on it.
And keeping the communication with Peter.
As, I can see now, the problem is in the r344756.
We can revert it, but we will get back to admbugs issues, so I am working on understanding the issue and finding correct fix.
A commit references this bug:
Date: Fri Mar 15 11:49:46 UTC 2019
New revision: 345179
Remove unneeded mount point unlock function calls.
The ext2_nodealloccg() function unlocks the mount point
in case of successful node allocation.
The additional unlocks are not required and should be removed.
Reported by: pho
MFC after: 3 days