Kernel monitor, the return

[Andrey Simonenko]

On Tue, Feb 22, 2005 at 03:34:41PM -0500, John Baldwin wrote:
> 
> You don't need sched_lock to check PS_INMEM, proc lock is sufficient
> (PS_INMEM is magic this way).

I suggested the author of the original letter to get lock on sched_lock,
because statclock() modifies ru_idrss and ru_isrss values and that
values are read in that kproc.  Having read some code in the kernel,
now I think that lock on sched_lock is needed only before reading
ru_idrss and ru_isrss for current thread.  Am I right?  (at least
getrusage() does in this way.)

In private letters we found that it is better to use _PHOLD/_PRELE
for that task.

> If you did though, you would lock proc first, then sched_lock.
> You can _not_ lock a regular mutex (proc lock) after a spin 
> mutex (sched_lock) or you can deadlock.

Thanks... mutex(9) also says about this.  I've just looked at sources
for mtx_lock_spin/unspin and for better understanding of meaning of
the sentence you wrote.