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>Received on Sat Nov 07 2020 - 16:00:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC