On Fri, Apr 08, 2022 at 11:07:22AM +0200, Alexander Bluhm wrote: > On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote: > > I have a diff for adding some stacktrace history for vnode (keeping track of > > lasts vref/vrele/vget/vput). but I am not sure it would be efficient to > > found > > the underline problem. > > Now it crashed with a different panic.
it is different only because vn_lock() checked if the vnode was on freelist (it is part of my diff). without this particular check, it would have fail just after in the code path with "vref used where vget required" panic. the problem is the uvm associated vnode doesn't have its v_usecount properly set. uvn_attach() referenced it, but "somebody" vrele/vput it whereas it shouldn't (missing vref ? race ? ...) Here, the vnode is already recycled to freelist when uvn_io() try to use it. In your previous mail, there is already a problem (v_usecount==0 too), but the vnode is still somehow "valid" (it isn't fully gone). with my last diff, it will be catched too. and I hope to infer possible problematic codepath with stacktrace history. > [-- MARK -- Thu Apr 7 20:40:00 2022] > uvn_io: start: 0x21627330, type VREG, use 0, write 0, hold 0, flags > (VBIOONFREELIST) > tag VT_UFS, ino 53519, on dev 0, 10 flags 0x100, effnlink 1, nlink 1 > mode 0100660, owner 21, group 21, size 13647873 > vn_lock: vnode on freelist: 0x21627330, type VREG, use 0, write 0, hold 0, > flags (VBIOONFREELIST) > tag VT_UFS, ino 53519, on dev 0, 10 flags 0x100, effnlink 1, nlink 1 > mode 0100660, owner 21, group 21, size 13647873 > panic: vn_lock: vp on freelist thanks. -- Sebastien Marie
