PERFORCE change 14877 for review

Bosko Milekic bmilekic at unixdaemons.com
Thu Jul 25 02:48:12 GMT 2002


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... :-(

> Affected files ...
> 
> .. //depot/projects/trustedbsd/mac/sys/kern/sys_pipe.c#13 edit
> 
> Differences ...
> 
> ==== //depot/projects/trustedbsd/mac/sys/kern/sys_pipe.c#13 (text+ko) ====
> 
> @@ -1369,7 +1369,7 @@
>  	/*
>  	 * Destroy MAC data
>  	 */
> -	if (cpipe->pipe_peer)
> +	if (cpipe->pipe_peer == NULL)
>  		mac_destroy_pipe(cpipe);
>  #endif /* MAC */
>  
> 

-- 
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



More information about the trustedbsd-cvs mailing list