From owner-freebsd-fs@freebsd.org Fri May 27 13:37:45 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0E5BB4B8A1 for ; Fri, 27 May 2016 13:37:45 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AEBF10EB for ; Fri, 27 May 2016 13:37:44 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from [192.168.100.101] (helo=aka) by mail1.yamagi.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1b6Hws-000PzM-KU; Fri, 27 May 2016 15:37:41 +0200 Date: Fri, 27 May 2016 15:37:05 +0200 From: Yamagi Burmeister 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> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 13:37:45 -0000 On Thu, 26 May 2016 18:58:44 +0300 Konstantin Belousov 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=, dummy2=, dummy3=, dummy4=) 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=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff80993279 in kdb_trap (type=3, code=0, tf=) 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=) at cpufunc.h:63 #9 0xffffffff809573b6 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:882 #10 0xffffffff80957269 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:777 #11 0xffffffff809b5aeb in witness_warn (flags=, lock=, fmt=) at /usr/src/sys/kern/subr_witness.c:1757 #12 0xffffffff809aa0a8 in userret (td=0xfffff800264c6960, frame=) at /usr/src/sys/kern/subr_trap.c:157 #13 0xffffffff80d78151 in amd64_syscall (td=0xfffff800264c6960, traced=) 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