I am fine with any optimization to this path you like, so long as locks are neutered in panic and don't cause secondary panics.
On Tue, Apr 24, 2018 at 4:22 PM, Mateusz Guzik <[email protected]> wrote: > On Tue, Apr 24, 2018 at 8:41 PM, Conrad Meyer <[email protected]> wrote: >> >> Author: cem >> Date: Tue Apr 24 18:41:14 2018 >> New Revision: 332957 >> URL: https://svnweb.freebsd.org/changeset/base/332957 >> >> Log: >> lockmgr: Add missed neutering during panic >> >> r313683 introduced new lockmgr APIs that missed the panic-time neutering >> present in the rest of our locks. Correct that by adding the usual >> check. >> >> Additionally, move the __lockmgr_args neutering above the assertions at >> the >> top of the function. Drop the interlock unlock because we shouldn't >> have >> an unneutered interlock either. No point trying to unlock it. >> >> PR: 227749 >> Reported by: jtl >> Sponsored by: Dell EMC Isilon >> >> Modified: >> head/sys/kern/kern_lock.c >> >> Modified: head/sys/kern/kern_lock.c >> >> ============================================================================== >> --- head/sys/kern/kern_lock.c Tue Apr 24 18:19:30 2018 (r332956) >> +++ head/sys/kern/kern_lock.c Tue Apr 24 18:41:14 2018 (r332957) >> @@ -918,6 +918,9 @@ lockmgr_lock_fast_path(struct lock *lk, u_int flags, s >> u_int op; >> bool locked; >> >> + if (__predict_false(panicstr != NULL)) >> + return (0); >> + >> > > This only further pollutes the slowpath. I mean fastpath. All the fallback > funcs check for panic, so there is no need to do it in regular kernels at > this level. > > Instead, the firing assertion should also see if perhaps the kernel > already has panicked. > > Alternatively, the checks added here can be conditional on INVARIANTS. > > -- > Mateusz Guzik <mjguzik gmail.com> _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
