svn commit: r332860 - head/sys/kern

[John Baldwin]

On Tuesday, April 24, 2018 01:24:30 PM Jonathan T. Looney wrote:
> On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin <jhb at freebsd.org> 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