From owner-freebsd-arch  Wed Oct  4  0:28: 6 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4345A37B502; Wed,  4 Oct 2000 00:28:02 -0700 (PDT)
Received: from netplex.com.au (peter@localhost [127.0.0.1])
	by netplex.com.au (8.11.0/8.9.3) with ESMTP id e947RpH19302;
	Wed, 4 Oct 2000 00:27:51 -0700 (PDT)
	(envelope-from peter@netplex.com.au)
Message-Id: <200010040727.e947RpH19302@netplex.com.au>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Chuck Paterson <cp@bsdi.com>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG,
	John Polstra <jdp@polstra.com>, Daniel Eischen <eischen@vigrid.com>,
	Matt Dillon <dillon@earth.backplane.com>, Greg Lehey <grog@lemis.com>
Subject: Re: Mutexes and semaphores 
In-Reply-To: <200010032129.PAA13697@berserker.bsdi.com> 
Date: Wed, 04 Oct 2000 00:27:51 -0700
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Chuck Paterson wrote:
> Your right, not freeing these things ever does make things
> lots easier.
> 
> Chuck

In the freebsd case, this is the case.  Zones are never cleaned up, and
certainly not unmapped.  zfree() will however cause the first few bytes
to be clobbered as they are reused for the freelist.

int
getppid(p, uap)
        struct proc *p;
        struct getppid_args *uap;
{
 
        p->p_retval[0] = p->p_pptr->p_pid;
        return (0);
}

could safely become:

int
getppid(p, uap)
	struct proc *p;
	struct getppid_args *uap;
{
	struct proc *parent;
	pid_t pid;

	parent = p->p_pptr;
	pid = parent->p_pid;
#ifdef SMP
	for (;;) {
		__asm __volatile (": : : memory");	/* mb(); on x86 */
		if (parent == p->p_pptr)
			break;
		/* lost a race, our parent died and we reparented - redo */
		parent = p->p_pptr;
		pid = parent->p_pid;
	}		
#endif
	p->p_retval[0] = (register_t)pid;
	return 0;
}

This isn't quite the same as the linux version, but I'm pretty sure the
important races are covered just like theirs.  The mb(); replacement could
be a real per-cpu mb instruction on arches that require it.  Even if it is
just the gcc flush, it would be sufficient for 99.99999% of cases.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message