PERFORCE change 107903 for review

[Divacky Roman]

On Mon, Oct 16, 2006 at 03:37:27PM -0400, John Baldwin wrote:
> On Saturday 14 October 2006 12:04, Roman Divacky wrote:
> > http://perforce.freebsd.org/chv.cgi?CH=107903
> > 
> > Change 107903 by rdivacky at rdivacky_witten on 2006/10/14 16:04:47
> > 
> > 	A bunch of fixes that makes this not panic when killpg() is called.
> > 
> > Affected files ...
> > 
> > .. //depot/projects/linuxolator/src/sys/compat/linux/linux_emul.c#10 edit
> > 
> > Differences ...
> > 
> > ==== //depot/projects/linuxolator/src/sys/compat/linux/linux_emul.c#10 
> (text+ko) ====
> > 
> > @@ -212,8 +212,12 @@
> >  	q = LIST_FIRST(&p->p_children);
> >  	for (; q != NULL; q = nq) {
> >  	   	nq = LIST_NEXT(q, p_sibling);
> > -		if (__predict_true(q->p_sysent != &elf_linux_sysvec))
> > -   		   	break;
> > +	   	PROC_LOCK(q);
> > +	   	if (q->p_flag & P_WEXIT)
> > +		   	continue;
> > +	   	PROC_UNLOCK(q);
> > +		if (__predict_false(q->p_sysent != &elf_linux_sysvec))
> > +   		   	continue;
> >     	   	em = em_find(q, EMUL_UNLOCKED);
> >  		KASSERT(em != NULL, ("linux_reparent: emuldata not found: %i\n", 
> q->p_pid));
> >  		if (em->pdeath_signal != 0) {
> 
> Holding the proc lock doesn't buy you anything here.  Probably you should hold 
> an slock of the proctree_lock while you walk the list, and that should be 
> good enough to test P_WEXIT.  However, even if you didn't hold it, grabbing 
> the lock just to do a read doesn't buy you anything as far as closing race 
> conditions.

I am already holding the proctree_lock... so I'll just remove the PROC_LOCK()
on the other hand.. I am very not sure about the locking I do but when I do it
otherwiuse I am getting a LOR... hard situation :(