On 28/04/22(Thu) 16:54, Sebastien Marie wrote:
> On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> > On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > > Here a new diff (sorry for the delay) which add a new 
> > > vnode_history_record()
> > > point inside uvn_detach() (when 'uvn' object has UVM_VNODE_CANPERSIST 
> > > flag sets).
> > 
> > [-- MARK -- Thu Apr 28 14:10:00 2022]
> > uvn_io: start: 0x23ae1400, type VREG, use 0, write 0, hold 0, flags 
> > (VBIOONFREELIST)
> >         tag VT_UFS, ino 495247, on dev 0, 10 flags 0x100, effnlink 1, nlink 
> > 1
> >         mode 0100660, owner 21, group 21, size 13647873
> > ==> vnode_history_print 0x23ae1400, next=6
> >  [3] c++[44194] usecount 2>1
> > #0  0x626946ec
> >  [4] reaper[10898] usecount 1>1
> > #0  entropy_pool0+0xf54
> 
> even if the stacktrace is somehow grabage, the "usecount 1>1" is due to 
> VH_NOP 
> (no increment neither decrement), so it is the vnode_history_record() newly 
> added at:
> 
> @@ -323,6 +325,10 @@ uvn_detach(struct uvm_object *uobj)
>          * let it "stick around".
>          */
>         if (uvn->u_flags & UVM_VNODE_CANPERSIST) {
> +               extern void vnode_history_record(struct vnode *, int);
> +
> +               vnode_history_record(vp, 0);
> +
>                 /* won't block */
>                 uvn_flush(uobj, 0, 0, PGO_DEACTIVATE|PGO_ALLPAGES);
>                 goto out;
> 
> mpi@, it confirms that uvn_flush() is called without PGO_FREE for this uvn.

Thanks!

Has vclean() been called for this vnode?  If so the problem might indeed
be related to the `uo_refs' fix I just committed, if not that might be
the bug.

Reply via email to