In message <20000523205829.D16862@dr-evil.shagadelic.org>, Jason R Thorpe writes:
>On Tue, May 23, 2000 at 11:32:48PM -0400, John Hawkinson wrote:
>
> > Is lockmgr() not supposed to be called in an interrupt context -- who
> > is to blame here?
>
>That depends.  If you drop into DDB via the console hot key and then
>issue "reboot", you are.

preferatory note: Do we know why this started to happen recently?
is it a result of more code running in the idle loop?


It's certainly the case that it is reasonable for ddb to call
reboot from an interrupt context, and if it is reasonable for
curproc to be NULL when the system is idle, then any function
expected to be called from an interrupt context should
expect curproc to be NULL, or a reasonably likelyhood thereof.

So that says to me that either vfs_shutdown() is wrong to be
calling lockmgr() [via vfs_unmuntall()->vfs_busy()->lockmgr()], or
lockmgr() is wrong to assume there is a current process.

Which is it? The latter I suspect.

Is it reasonable for lockmgr() to iuse one of:

#define LK_KERNPROC     ((pid_t) -2)
#define LK_NOPROC       ((pid_t) -1)

when curproc is NULL?

--jhawk