PERFORCE change 14877 for review

[Bosko Milekic]

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 at 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 at fledge.watson.org      Network Associates Laboratories

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

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message