svn commit: r332957 - head/sys/kern

[Conrad Meyer]

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 <mjguzik at gmail.com> wrote:
> On Tue, Apr 24, 2018 at 8:41 PM, Conrad Meyer <cem at freebsd.org> 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>