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 <mjgu...@gmail.com> wrote: > On 11/6/20, Andriy Gapon <a...@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> _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
