Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jul 2002 19:49:04 -0400
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 14877 for review
Message-ID:  <20020727194904.A38779@unixdaemons.com>
In-Reply-To: <Pine.NEB.3.96L.1020727191945.24317B-100000@fledge.watson.org>; from rwatson@freebsd.org on Sat, Jul 27, 2002 at 07:20:38PM -0400
References:  <20020724224812.A1630@unixdaemons.com> <Pine.NEB.3.96L.1020727191945.24317B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, Jul 27, 2002 at 07:20:38PM -0400, Robert Watson wrote:
> 
> On Wed, 24 Jul 2002, Bosko Milekic wrote:
> 
> > On Wed, Jul 24, 2002 at 07:21:38PM -0700, Robert Watson wrote:
> > > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=14877
> > > 
> > > Change 14877 by rwatson@rwatson_curry on 2002/07/24 19:21:02
> > > 
> > > 	Hopefully a bug fix for a bug whereby when one pipe end is
> > > 	terminated, the label is prematurely destroyed, resulting in
> > > 	a blank label during follow-up policy checks.  I believe this
> > > 	change modifies the logic so that the pipe label is destroyed
> > > 	only when the second end-point is removed.  We'll see if this
> > > 	corrects the problem I'm bumping into.
> > 
> >    Since you have one mutex and one label for both ends of the
> >    bi-directional pipe, why don't you just use the code already in place
> >    for destroying the mutex 'safely' to also destroy the label?  In
> >    other words, pipeclose() has this `hadpeer' variable which it
> >    increments if it finds that the other end exists (and the mutex is
> >    grabbed, then).  In other words, just group the label destroy with
> >    the mutex destroy.  If one is wrong, they're both wrong and you can
> >    fix them both at the same time.  I think that you should only be
> >    destroying the label if it hasn't already been initialized, as well.
> >    It could be that this is a partially created pipe and so the mutex
> >    (and possibly the label?) have not yet been created.  I would examine
> >    this further myself but it'll have to wait... :-(
> 
> Yeah, I think there may be windows where for fdesc-shared processes (and
> presumably KSE's), the pipe is present but not yet available.  An
> interesting question is whether you can perform pipe operations in the
> window, and if so, whether we need to initialize the labels earlier, and
> destroy them later.

  I'm actually looking at this today and should be able to come up with
  either confirmation that it's correct or a fix.  What I initially
  thought was a problem may in fact not be, but when I come up with
  something, if anything, I'll send you the diff.

> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org      Network Associates Laboratories

-- 
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.org


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




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