Date: Fri, 27 May 2016 15:37:05 +0200 From: Yamagi Burmeister <lists@yamagi.org> To: kostikbel@gmail.com Cc: freebsd-fs@freebsd.org Subject: Re: LOR between allproc <-> ufs Message-ID: <20160527153705.ee502c0a528cedd29c65b0ca@yamagi.org> In-Reply-To: <20160526155844.GH38613@kib.kiev.ua> References: <20160526160902.bbe4c36ad340f11f69f7ba08@yamagi.org> <20160526155844.GH38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 May 2016 18:58:44 +0300
Konstantin Belousov <kostikbel@gmail.com> wrote:
> Completely untested patch is below. I do not think that this LOR
> can be reproduced at will. E.g. you need to record the order
> in witness by unmounting some filesystem mounted on a directory
> on UFS mount. Then, the chances must be that it was the last
> reference on the vmspace, or that there were deferred vnode entry.
With this patch the system panics as soon there's some load on the
filesystem. Maybe only when several processes accessing the same
mountpoint, but I'm not sure. For example 'make -j24 buildkernel'
crashes the system nearly instantly.
(kgdb) bt
#0 doadump (textdump=165043200) at pcpu.h:219
#1 0xffffffff80357b45 in db_fncall (dummy1=<value optimized out>, dummy2=<value optimized out>,
dummy3=<value optimized out>, dummy4=<value optimized out>)
at /usr/src/sys/ddb/db_command.c:568
#2 0xffffffff8035782d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440
#3 0xffffffff803575a4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493
#4 0xffffffff80359f80 in db_trap (type=<value optimized out>, code=0) at /usr/src/sys/ddb/db_main.c:231
#5 0xffffffff80993279 in kdb_trap (type=3, code=0, tf=<value optimized out>)
at /usr/src/sys/kern/subr_kdb.c:656
#6 0xffffffff80d7713e in trap (frame=0xfffffe10440c2730) at /usr/src/sys/amd64/amd64/trap.c:561
#7 0xffffffff80d5af52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#8 0xffffffff809929de in kdb_enter (why=0xffffffff81010020 "panic", msg=<value optimized out>)
at cpufunc.h:63
#9 0xffffffff809573b6 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:882
#10 0xffffffff80957269 in kassert_panic (fmt=<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:777
#11 0xffffffff809b5aeb in witness_warn (flags=<value optimized out>, lock=<value optimized out>,
fmt=<value optimized out>) at /usr/src/sys/kern/subr_witness.c:1757
#12 0xffffffff809aa0a8 in userret (td=0xfffff800264c6960, frame=<value optimized out>)
at /usr/src/sys/kern/subr_trap.c:157
#13 0xffffffff80d78151 in amd64_syscall (td=0xfffff800264c6960, traced=<value optimized out>)
at subr_syscall.c:185
#14 0xffffffff80d5b23b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396
#15 0x0000000802ef665a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
This time I've got a dump, so further information can be provided.
Regards,
Yamagi
--
Homepage: www.yamagi.org
XMPP: yamagi@yamagi.org
GnuPG/GPG: 0xEFBCCBCB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160527153705.ee502c0a528cedd29c65b0ca>