On Mon, Jul 24, 2006 at 03:25:49PM +0200, Elad Efrat wrote:
> Andrew Doran wrote:
> 
> >                 proclist_lock_read();
> >                 PROCLIST_FOREACH(p, &allproc) {
> >                         if (kauth_authorize_process(l->l_cred,
> >                             KAUTH_PROCESS_CANSEE, p, NULL, NULL, NULL) != 0)
> >                                 continue;
> > 			[...]
> > 		}
> > 		proclist_unlock_read();
> > 
> > I don't fully understand the implication of kauth in this setting, other
> > than providing permission to touch another process. In what situations might
> > it want to sleep?
> 
> the locking is not something kauth(9) added; it was there before to
> prevent modification of allproc while traversing it. i admit i'm not
> sure how to deal with this one. :)

It is (almost) possible to traverse all processes without holding the
proclist lock throughout provided that you:
1) don't mind not seeing processes that are created after you start
2) somehow disable the 'splitting' of the proclist table that is done
   when it becomes full.  IIRC handling a single split is relatively easy.
The problem with the first is that a process can hide from you by doing
lots of forks and exiting in the child.

The other issue is that the process pointer returned by the pid lookup
(or any other method) can become invalid as soon as you release the lock.
(I don't remember there being a reference count in the proc structure.)

	David

-- 
David Laight: david@l8s.co.uk