Kernel monitor, the return

[John Baldwin]

On Tuesday 15 February 2005 08:20 am, Andrey Simonenko wrote:
> On Mon, Feb 14, 2005 at 10:24:50PM -0800, Ashwin Chandra wrote:
> > In trying to create a simple kernel thread that prints out all
> > the processes data and stack size, i still get a panic fault
> > (vm_fault on no entry) at the printf statement...ive narrowed
> > it down to the ru_idrss variable that is causing the problem,
>
> Definitely ru_idrss cannot cause any error, may be you made
> such desition, because arguments are pushed to the stack
> in the reverse order.  p->p_stats pointer causes the error.
>
> > im not sure why
>
> (I think that) If some process is not running, then you cannot
> use p->p_stats without additional checks for memory p->p_stats
> points to, since p->p_stats points to u_stats in struct user{},
> which can be swapped out if a process is not running.
>
> Actually you can read this in the comment before struct user{}
> in /sys/sys/user.h.
>
> >. I thought maybe I was not locking properly or
> > obseriving correct mutexes, but I have tried everything.
>
> You'll get an error at some time, because of incorrect usage
> (really not usage) of locks.
>
> > If anyone
> > knows why the fault is occurring at the printf, please let me know. =)
>
> Following code works on my system:
>
> ----
>
> 	sx_slock(&allproc_lock);
>
> 	FOREACH_PROC_IN_SYSTEM(p) {
> 		mtx_lock_spin(&sched_lock);
> 		PROC_LOCK(p);
> 		printf("proc %ld:", (long)p->p_pid);
> 		if ((p->p_sflag & PS_INMEM) && p->p_stats != NULL)
> 			printf(" ru_isrss %ld, rui_idrss %ld\n", p->p_stats->p_ru.ru_isrss,
> p->p_stats->p_ru.ru_idrss); else {
> 			if (!(p->p_sflag & PS_INMEM))
> 				printf(" !PS_INMEM");
> 			if (p->p_stats == NULL)
> 				printf(" p_stats == NULL");
> 		}
> 		printf("\n");
> 		PROC_UNLOCK(p);
> 		mtx_unlock(&sched_lock);
> 	}
>
> 	sx_sunlock(&allproc_lock);

You don't need sched_lock to check PS_INMEM, proc lock is sufficient (PS_INMEM 
is magic this way).  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.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org