On 07/11/2020 19:00, Mateusz Guzik wrote: > Fixed as of r367454 (also see r367453).
Thank you! > On 11/6/20, Mateusz Guzik <mjgu...@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 <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> >> > > -- Andriy Gapon _______________________________________________ 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"
