Re: LOCKDEBUG_BARRIER in mi_userret (was: Re: Another force unmount failure)

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Fri, 17 Jul 2015 18:37:30 +0200
   From: manu%netbsd.org@localhost (Emmanuel Dreyfus)

   Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:

   > `Last locked' tells you the return address of the call to rw_enter
   > that last acquired the lock.  (The other addresses may be useful for
   > other lockdebug panics but aren't likely to be of much use here.)

   Here is the code. The function cannot exit without vp->v_interlock being
   unlocked. What does that means? 

   (gdb) list *0xc018b217
   0xc018b217 is in genfs_lock
   (../../../../miscfs/genfs/genfs_vnops.c:385).
   380                     return error;
   381             }
   382     
   383             fstrans_start(mp, FSTRANS_SHARED);
   384             rw_enter(&vp->v_lock, op);
   385             mutex_enter(vp->v_interlock);

What's locked is not vp_interlock, but v_lock.  The address c018b217
or line 385 is the return address of the lock, i.e. what happens
afterward.

Since this is in genfs_lock, what happened here is almost certainly
that you locked a vnode but didn't unlock it.  Unfortunately,
lockdebug does not provide a full stack trace, so you'll have to guess
where the relevant vn_lock was.

(Perhaps we ought to put extra lockdebug crud in vn_lock and a new
vn_unlock in order to track these things down more usefully.)