From owner-svn-src-head@freebsd.org Tue Apr 24 18:15:37 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB26EFAE6EC; Tue, 24 Apr 2018 18:15:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54F0168FF3; Tue, 24 Apr 2018 18:15:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id E59E110B45D; Tue, 24 Apr 2018 14:15:35 -0400 (EDT) From: John Baldwin To: "Jonathan T. Looney" Cc: Mark Johnston , cem@freebsd.org, src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332860 - head/sys/kern Date: Tue, 24 Apr 2018 10:45:54 -0700 Message-ID: <1701991.xdIdhqUnOe@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <201804211705.w3LH50Dk056339@repo.freebsd.org> <1739228.8pyHcvzasL@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 24 Apr 2018 14:15:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 18:15:37 -0000 On Tuesday, April 24, 2018 01:24:30 PM Jonathan T. Looney wrote: > On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin wrote: > > > > I think this is actually a key question. In my experience to date I have > not > > encountered a large number of post-panic assertion failures. Given that > > we already break all locks and disable assertions for locks I'd be curious > > which assertions are actually failing. My inclination given my > experiences > > to date would be to explicitly ignore those as we do for locking if it is > > constrained set rather than blacklisting all of them. However, I would be > > most interested in seeing some examples of assertions that are failing. > > The latest example (the one that prompted me to finally commit this) is in > lockmgr_sunlock_try(): 'panic: Assertion (*xp & ~LK_EXCLUSIVE_SPINNERS) == > LK_SHARERS_LOCK(1) failed at /usr/src/sys/kern/kern_lock.c:541' So that's one of the few assertions in a locking primitive that hasn't been explicitly neutered. I would neuter it explicitly by adjusting that assertion to not fail if panicstr != NULL. lockmgr() itself is mostly neutered already, though I would move the existing panicstr check in _lockmgr_args slightly higher above the list of KASSERT()'s. I would say this is just a bug in lockmgr in that it isn't careful to break locks and ignore assertions during a panic. I consider locking assertions to be a class that should be neutered, but I think it's a different argument to expand that to ignoring all assertions. Do you have any examples of non-locking assertions? > I don't see any obvious recent changes that would have caused this, so this > is probably a case where a change to another file suddenly made us trip > over this assert. It's arguably a bug in r313683 which is only a year old. -- John Baldwin