Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed

On 07/11/2020 19:00, Mateusz Guzik wrote:
> Fixed as of r367454 (also see r367453).

Thank you!

> On 11/6/20, Mateusz Guzik <mjguzik_at_gmail.com> wrote:
>> I think I have an idea how to keep this. In the meantime you can just
>> comment it out.
>>
>> On 11/6/20, Mateusz Guzik <mjguzik_at_gmail.com> wrote:
>>> On 11/6/20, Andriy Gapon <avg_at_freebsd.org> wrote:
>>>> On 06/11/2020 22:58, Mateusz Guzik wrote:
>>>>> Note the underlying primitive was recently replaced.
>>>>>
>>>>> One immediate thing to check would be exact state of the lock.
>>>>> READ_HELD checks for reading only, fails if you have this
>>>>> write-locked, which is a plausible explanation if you are coming in
>>>>> from less likely codepath.
>>>>>
>>>>> iow what's the backtrace and can you print both rms->readers and
>>>>> rms->owner (+ curthread)
>>>>
>>>> Unfortunately, I do not have a vmcore, only a picture of the screen.
>>>>
>>>> ZFS code looks correct, the lock should be held in read mode, so indeed
>>>> I
>>>> suspect that the problem is with rms.
>>>>
>>>> It looks like rms_rlock() does not change rmslock::readers, but
>>>> rms_rowned()
>>>> checks it?
>>>>
>>>> That's just from a first, super-quick look at the code.
>>>>
>>>
>>> Heh, now that you mention it, I remember wanting to just remove the
>>> arguably spurious assert. Linux is never doing it for reading. The
>>> only state asserts made are for writing which works fine.
>>>
>>> As for reading assertions, there is no performant way to make it work
>>> and I don't think it is worth it as it is.
>>>
>>> As such, I vote for just removing these 2 asserts. They really don't
>>> buy anything to begin with.
>>>
>>> --
>>> Mateusz Guzik <mjguzik gmail.com>
>>>
>>
>>
>> --
>> Mateusz Guzik <mjguzik gmail.com>
>>
> 
> 


-- 
Andriy Gapon