Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Oct 2006 10:14:42 +0200
From:      Divacky Roman <xdivac02@stud.fit.vutbr.cz>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Roman Divacky <rdivacky@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 107903 for review
Message-ID:  <20061017081441.GA73503@stud.fit.vutbr.cz>
In-Reply-To: <200610161537.27772.jhb@freebsd.org>
References:  <200610141604.k9EG4x8o040869@repoman.freebsd.org> <200610161537.27772.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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 :(



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061017081441.GA73503>