panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed

[Mateusz Guzik]

Fixed as of r367454 (also see r367453).

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>
>


-- 
Mateusz Guzik <mjguzik gmail.com>