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 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 wrote: >>> On 11/6/20, Andriy Gapon 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 >>> >> >> >> -- >> Mateusz Guzik >> > > -- 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
Fixed as of r367454 (also see r367453). On 11/6/20, Mateusz Guzik 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 wrote: >> On 11/6/20, Andriy Gapon 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 >> > > > -- > Mateusz Guzik > -- Mateusz Guzik ___ 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
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 wrote: > On 11/6/20, Andriy Gapon 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 > -- Mateusz Guzik ___ 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
On 11/6/20, Andriy Gapon 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 ___ 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
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. > On 11/6/20, Andriy Gapon wrote: >> >> The subject panic happens for me with r367410 when mounting root >> filesystem. >> The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. >> I have a picture of the screen with a little bit more details, I'll share it >> later. -- 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
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) On 11/6/20, Andriy Gapon wrote: > > The subject panic happens for me with r367410 when mounting root > filesystem. > The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. > I have a picture of the screen with a little bit more details, I'll share it > later. > > -- > 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" > -- Mateusz Guzik ___ 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"
panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
The subject panic happens for me with r367410 when mounting root filesystem. The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. I have a picture of the screen with a little bit more details, I'll share it later. -- 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"
