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 21:17:43 +0200
   From: manu%netbsd.org@localhost (Emmanuel Dreyfus)

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

   > 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.

   If there any change to at least get the syscall number?

In theory, yes -- it is put on the stack when control enters the
syscall vector, and the `SPL NOT LOWERED AFTER EXIT' error gets at it,
in, e.g., arch/amd64/amd64/locore.S.  But I'm not sure there's an easy
way to get at it otherwise.  From a core dump, you could perhaps
grovel through the stack to find it, if you were dedicated enough.

As an alternative, I could imagine putting another LOCKDEBUG_BARRIER
inside sy_invoke, and modifying LOCKDEBUG_BARRIER to take a formatted
string which, in this case, would be used to show the syscall number.