From marcolz@rave.ilse.net  Mon Mar 14 16:31:15 2005
Return-Path: <marcolz@rave.ilse.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F17C216A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Mar 2005 16:31:15 +0000 (GMT)
Received: from rave.ilse.net (pip0-6.ilse.nl [62.69.162.176])
	by mx1.FreeBSD.org (Postfix) with ESMTP id F36AB43D31
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Mar 2005 16:31:14 +0000 (GMT)
	(envelope-from marcolz@rave.ilse.net)
Received: from rave.ilse.net (localhost.ilse.nl [127.0.0.1])
	by rave.ilse.net (8.13.3/8.13.1) with ESMTP id j2EGVDeu035757
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 14 Mar 2005 17:31:13 +0100 (CET)
	(envelope-from marcolz@rave.ilse.net)
Received: (from marcolz@localhost)
	by rave.ilse.net (8.13.3/8.13.1/Submit) id j2EGVCH2035756;
	Mon, 14 Mar 2005 17:31:12 +0100 (CET)
	(envelope-from marcolz)
Message-Id: <200503141631.j2EGVCH2035756@rave.ilse.net>
Date: Mon, 14 Mar 2005 17:31:12 +0100 (CET)
From: Marc Olzheim <zlo@zlo.nu>, Sven Berkvens <sven@berkvens.net>
Reply-To: Marc Olzheim <zlo@zlo.nu>,
	Sven Berkvens <sven@berkvens.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: race condition close()ing and read()ing the same socketpair on SMP.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         78824
>Category:       kern
>Synopsis:       race condition close()ing and read()ing the same socketpair on SMP.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 14 16:40:02 GMT 2005
>Closed-Date:    Sat Jun 11 08:01:20 GMT 2005
>Last-Modified:  Sun Jul  3 00:30:36 GMT 2005
>Originator:     Marc Olzheim, Sven Berkvens
>Release:        FreeBSD 5.4-PRERELEASE i386
>Organization:
ilse media
>Environment:
System: FreeBSD rave.ilse.net 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Thu Mar 10 15:43:26 CET 2005 root@rave.ilse.net:/usr/obj/usr/src/sys/SE3DEBUG i386

GENERIC + INVARIANTS + INVARIANT_SUPPORT + WITNESS + WITNESS_SKIPSPIN

>Description:
	When read()ing from a socket while the other end is being
	close()d at the same time, read() fails with errno == ENOTCONN,
	instead of doing normal End-of-file handling.

	References:
	soisdisconnected() from
	__FBSDID("$FreeBSD: src/sys/kern/uipc_socket2.c,v 1.137.2.5 2005/02/23 00:39:17 rwatson Exp $");
	soreceive() from
	__FBSDID("$FreeBSD: src/sys/kern/uipc_socket.c,v 1.208.2.17 2005/03/07 13:08:03 rwatson Exp $");
	close() from
	__FBSDID("$FreeBSD: src/sys/kern/kern_descrip.c,v 1.243.2.6 2005/03/03 22:27:32 jhb Exp $");

	It seems as though soreceive() doesn't check for a lock on the
	filedescriptor, just the socket buffer, allowing close() to
	modify its flags at the same time.

>How-To-Repeat:
	Since this is heavily timing dependant (it is a race condition),
	it might not be easily reproduced. We can run our code on the
	following hardware, with no other CPU-time consuming processes
	running to reproduce it:

hw.machine: i386
hw.model: Intel(R) Xeon(TM) CPU 3.06GHz
hw.ncpu: 4
hw.byteorder: 1234
hw.clockrate: 3065
kern.ostype: FreeBSD
kern.osrelease: 5.4-PRERELEASE
kern.osrevision: 199506
kern.version: FreeBSD 5.4-PRERELEASE #0: Thu Mar 10 15:43:26 CET 2005
    root@rave.ilse.net:/usr/obj/usr/src/sys/SE3DEBUG

kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }
kern.osreldate: 503105
kern.stackprot: 7
kern.ktrace.genio_size: 4096
kern.ktrace.request_pool: 100
kern.sched.name: 4BSD
kern.smp.maxcpus: 16
kern.smp.active: 1
kern.smp.disabled: 0
kern.smp.cpus: 4
kern.smp.forward_signal_enabled: 1
kern.smp.forward_roundrobin_enabled: 1

	Here's the code. I run under ktrace on our machine, the problem
	is reproduced:

rave:/tmp>echo 'ktrace -i ./socketpair2 < /dev/null' | sh
<Socket is not connected> (3,4) (i:33)
<Socket is not connected> (3,4) (i:48)
<Socket is not connected> (3,4) (i:67)
<Socket is not connected> (3,4) (i:99)
100
<Socket is not connected> (3,4) (i:131)
<Socket is not connected> (3,4) (i:141)
<Socket is not connected> (3,4) (i:144)
<Socket is not connected> (3,4) (i:159)
<Socket is not connected> (3,4) (i:169)
<Socket is not connected> (3,4) (i:176)
<Socket is not connected> (3,4) (i:183)
200
<Socket is not connected> (3,4) (i:213)
<Socket is not connected> (3,4) (i:226)
<Socket is not connected> (3,4) (i:234)
<Socket is not connected> (3,4) (i:254)
<Socket is not connected> (3,4) (i:282)
...

	socketpair2.c:

/* socketpair2.c: -	Marc Olzheim <zlo at zlo.nu>,
 *			Sven Berkvens <sven at berkvens.net>
 */
#include	<errno.h>
#include	<fcntl.h>
#include	<stdio.h>
#include	<string.h>
#include	<signal.h>
#include	<sys/socket.h>
#include	<sys/types.h>
#include	<sys/wait.h>
#include	<unistd.h>

int
main(int argc, char *argv[])
{
	int	sock[2], i, j, wstat;
	char	buf[1024];
	ssize_t	bytes;
	pid_t	newpid;

	if (1 != argc)
	{
		fprintf(stderr, "Usage: %s\n", argv[0]);
		return 1;
	}

	for (i = 0;;++i)
	{
		if (socketpair(PF_UNIX, SOCK_STREAM, 0, sock))
			perror("socketpair()");

		newpid = fork();
		if (-1 == newpid)
			perror("fork()");

		if (0 != newpid)
		{
			/* parent */
			close(sock[1]);

			if (write(sock[0], "A", 1) != 1)
				perror("write()");

			/* Suspend until the child has read the byte. */
			kill(getpid(), SIGSTOP);

			/* We hopefully get a time slice as soon as as a
			 * SIGCONT it delivered.
			 */
			close(sock[0]);
		}
		else
		{
			/* child */
			close(sock[0]);

			bytes = read(sock[1], buf, 1);
			if (bytes != 1)
				perror("first read()");

			/* Tell the parent to continue and close his side of
			 * the socket.
			 */
			kill(getppid(), SIGCONT);

			/* Since only 1 byte is send, this should
			 * produce EOF.
			 */
			bytes = read(sock[1], buf, 1);
			if (bytes == -1)
			{
				printf("<%s> (%d,%d) (i:%d)\n",
					strerror(errno),
					sock[0], sock[1], i);
				exit(1);
			}

			exit(0);
		}

		wait(&wstat);

		if (!(i % 100) && i)
			printf("%d\n", i);
	}

	return 0;
}

>Fix:

	It's possible to catch the ENOTCONN and restart the read() to to
	read the EOF...

>Release-Note:
>Audit-Trail:

From: Marc Olzheim <zlo@zlo.nu>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Mon, 14 Mar 2005 18:13:08 +0100

 Kernel config includes SMP support btw.
 
 Marc

From: Marc Olzheim <zlo@zlo.nu>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <zlo@zlo.nu>, Sven Berkvens <sven@berkvens.net>
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Mon, 14 Mar 2005 18:48:27 +0100

 The ktrace output produced is at
 http://www.stack.nl/~marcolz/FreeBSD/kern-78824.ktrace.txt
 
 Marc
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Tue Mar 15 15:09:05 GMT 2005 
Responsible-Changed-Why:  
Grab ownership of this PR, since it sounds directly related to the work 
I've been doing. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=78824 

From: Marc Olzheim <marcolz@stack.nl>
To: bug-followup@FreeBSD.org, rwatson@freebsd.org
Cc: freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Tue, 3 May 2005 17:00:14 +0200

 Is this going to be fixed before 5.4 ? It still breaks on today's
 5.4-STABLE.
 
 Marc

From: Marc Olzheim <marcolz@stack.nl>
To: bug-followup@FreeBSD.org, rwatson@freebsd.org
Cc: freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Tue, 10 May 2005 15:10:05 +0200

 --HlL+5n6rz5pIUxbD
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Tue, May 03, 2005 at 05:00:14PM +0200, Marc Olzheim wrote:
 > Is this going to be fixed before 5.4 ? It still breaks on today's
 > 5.4-STABLE.
 
 As this is the only issue known to me now, that I don't have a patch
 for and is standing in my way of upgrading from FreeBSD 4.x to 5.x, I
 would like to know whether this is a simple bug that could be fixed in a
 second or not...
 If there are any issues (like being able to reproduce it) or not, please
 let me know where I can be of assistance.
 
 Marc
 
 --HlL+5n6rz5pIUxbD
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.1 (FreeBSD)
 
 iD8DBQFCgLKtezjnobFOgrERAvEoAJ9yjUDGawkCEHCITRDlES1HxV6bVACgj1LF
 fxpjI6iLILBnwxqEVxxhbpE=
 =cQit
 -----END PGP SIGNATURE-----
 
 --HlL+5n6rz5pIUxbD--

From: Robert Watson <rwatson@FreeBSD.org>
To: Marc Olzheim <marcolz@stack.nl>
Cc: bug-followup@FreeBSD.org, freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same
 socketpair on SMP.
Date: Tue, 10 May 2005 14:25:32 +0100 (BST)

 On Tue, 10 May 2005, Marc Olzheim wrote:
 
 > On Tue, May 03, 2005 at 05:00:14PM +0200, Marc Olzheim wrote:
 >> Is this going to be fixed before 5.4 ? It still breaks on today's
 >> 5.4-STABLE.
 >
 > As this is the only issue known to me now, that I don't have a patch for 
 > and is standing in my way of upgrading from FreeBSD 4.x to 5.x, I would 
 > like to know whether this is a simple bug that could be fixed in a 
 > second or not... If there are any issues (like being able to reproduce 
 > it) or not, please let me know where I can be of assistance.
 
 Marc,
 
 I'll try to take a look at it on the plane today.  I've mostly been on 
 travel the last month, so haven't had a chance to investigate in detail as 
 yet.  Sorry about that, and thanks for the report!
 
 Robert N M Watson
Responsible-Changed-From-To: rwatson->gnn 
Responsible-Changed-By: gnn 
Responsible-Changed-When: Wed May 11 14:43:37 GMT 2005 
Responsible-Changed-Why:  
Hopefully I have a bit more time to fix this than Robert does. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78824 

From: Robert Watson <rwatson@FreeBSD.org>
To: Marc Olzheim <marcolz@stack.nl>
Cc: bug-followup@FreeBSD.org, freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same
 socketpair on SMP.
Date: Fri, 27 May 2005 12:47:28 +0100 (BST)

 On Tue, 10 May 2005, Marc Olzheim wrote:
 
 > On Tue, May 03, 2005 at 05:00:14PM +0200, Marc Olzheim wrote:
 >> Is this going to be fixed before 5.4 ? It still breaks on today's
 >> 5.4-STABLE.
 >
 > As this is the only issue known to me now, that I don't have a patch for 
 > and is standing in my way of upgrading from FreeBSD 4.x to 5.x, I would 
 > like to know whether this is a simple bug that could be fixed in a 
 > second or not... If there are any issues (like being able to reproduce 
 > it) or not, please let me know where I can be of assistance.
 
 Hmm.  I'm unable to reproduce this on local SMP hardware, although I can 
 see at least one way that the race could occur.  Could you try the 
 attached patch and see if it helps matters?  This is a slight shot in the 
 dark but closes at least two races in the transition of socket state with 
 respect to socket buffer state.
 
 Robert N M Watson
 
 Index: uipc_socket2.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
 retrieving revision 1.145
 diff -u -r1.145 uipc_socket2.c
 --- uipc_socket2.c	12 Mar 2005 13:39:39 -0000	1.145
 +++ uipc_socket2.c	27 May 2005 11:34:03 -0000
 @@ -159,15 +159,12 @@
   {
 
   	/*
 -	 * XXXRW: This code separately acquires SOCK_LOCK(so) and
 -	 * SOCKBUF_LOCK(&so->so_rcv) even though they are the same mutex to
 -	 * avoid introducing the assumption  that they are the same.
 +	 * XXXRW: This code assumes that SOCK_LOCK(so) and
 +	 * SOCKBUF_LOCK(&so->so_rcv) are the same.
   	 */
 -	SOCK_LOCK(so);
 +	SOCKBUF_LOCK(&so->so_rcv);
   	so->so_state &= ~SS_ISCONNECTING;
   	so->so_state |= SS_ISDISCONNECTING;
 -	SOCK_UNLOCK(so);
 -	SOCKBUF_LOCK(&so->so_rcv);
   	so->so_rcv.sb_state |= SBS_CANTRCVMORE;
   	sorwakeup_locked(so);
   	SOCKBUF_LOCK(&so->so_snd);
 @@ -182,16 +179,12 @@
   {
 
   	/*
 -	 * XXXRW: This code separately acquires SOCK_LOCK(so) and
 -	 * SOCKBUF_LOCK(&so->so_rcv) even though they are the same mutex to
 -	 * avoid introducing the assumption  that they are the same.
 +	 * XXXRW: This code assumes that SOCK_LOCK(so) and
 +	 * SOCKBUF_LOCK(&so->so_rcv) are the same.
   	 */
 -	/* XXXRW: so_state locking? */
   	SOCK_LOCK(so);
   	so->so_state &= ~(SS_ISCONNECTING|SS_ISCONNECTED|SS_ISDISCONNECTING);
   	so->so_state |= SS_ISDISCONNECTED;
 -	SOCK_UNLOCK(so);
 -	SOCKBUF_LOCK(&so->so_rcv);
   	so->so_rcv.sb_state |= SBS_CANTRCVMORE;
   	sorwakeup_locked(so);
   	SOCKBUF_LOCK(&so->so_snd);

From: Marc Olzheim <marcolz@ilse.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Fri, 27 May 2005 14:16:24 +0200

 On an old kernel (Tue May  3 16:06:59 CEST 2005) I can reproduce it, but
 I can successfully work around it by giving the machine something to do,
 like start dnetc.
 
 On a new kernel (Wed May 25 15:15:28 CEST 2005) I can't reproduce it
 anymore...

From: Marc Olzheim <marcolz@stack.nl>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@FreeBSD.org,
	freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Fri, 27 May 2005 15:44:41 +0200

 On Fri, May 27, 2005 at 12:47:28PM +0100, Robert Watson wrote:
 > Hmm.  I'm unable to reproduce this on local SMP hardware, although I can 
 > see at least one way that the race could occur.  Could you try the 
 > attached patch and see if it helps matters?  This is a slight shot in the 
 > dark but closes at least two races in the transition of socket state with 
 > respect to socket buffer state.
 
 I'll cvsup back to 2005.05.03 (where I can reproduce it easily) and
 apply your patch and see what happens.
 
 Race conditions and reproducability are not terms that go together
 well. :-(
 
 Marc

From: Marc Olzheim <marcolz@stack.nl>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@FreeBSD.org,
	freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Fri, 27 May 2005 16:57:57 +0200

 --z4+8/lEcDcG5Ke9S
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Fri, May 27, 2005 at 03:44:41PM +0200, Marc Olzheim wrote:
 > Could you try the attached patch and see if it helps matters?  This is
 > a slight shot in the dark but closes at least two races in the
 > transition of socket state with respect to socket buffer state.
 
 Yes! This fixes it, on the tag=RELENG_5 date=2005.03.03.00.00.00 kernel.
 
 I'll try and see if it works on a recent RELENG_5 kernel as well, later.
 
 Marc
 
 --z4+8/lEcDcG5Ke9S
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.1 (FreeBSD)
 
 iD8DBQFClzV1ezjnobFOgrERAqBVAJ4psR4E3/yfaNjpvMmgwo765/klLQCfV/fH
 hI7dWu2IF+tqEoGiWzJ8Yo0=
 =qeu2
 -----END PGP SIGNATURE-----
 
 --z4+8/lEcDcG5Ke9S--
State-Changed-From-To: open->patched 
State-Changed-By: rwatson 
State-Changed-When: Sun May 29 15:33:13 GMT 2005 
State-Changed-Why:  
I've committed a possible fix (tested by the submitter) as 
uipc_socket2.c:1.146 in HEAD (6-CURRENT).  I've set an MFC after 
of 2 weeks, to see if any issues shake out.  Here's the commit 
message: 

revision 1.146 
date: 2005/05/27 17:16:43;  author: rwatson;  state: Exp;  lines: +6 -13 
In the current world order, each socket has two mutexes: a mutex 
that protects socket and receive socket buffer state, and a second 
mutex to protect send socket buffer state.  In some places, the 
mutex shared between the socket and receive socket buffer will be 
acquired twice, once by each layer, resulting in some 
inconsistency, but providing the abstraction benefit of being able 
to more easily separate the two mutexes in the future if desired. 

When transitioning a socket to the SS_ISDISCONNECTING or 
SS_ISDISCONNECTED states, grab the socket/receive socket buffer lock 
once rather than grabbing it as the socket lock, modifying socket 
state, then grabbing a second time as the receive lock in order to 
modify the socket buffer state to indicate no further data can be 
read.  This change is believed to close a race between the change in 
socket state and the change in socket buffer state, which for a 
remotely initiated close on a UNIX domain socket, resulted in 
soreceive() returning ENOTCONN rather than an EOF condition. 

A similar race still exists in the case of send, however, and is 
harder to fix as the socket and send socket buffer mutexes are not 
the same, and we would like to avoid holding combinations of socket 
mutexes over sb_upcall until we've finished clarifying the locking 
protocol for upcalls. 

This change has the side affect of reducing the number of mutex 
operations to initiate disconnect or perform disconnect on a 
socket by two. 

PR:             78824 
Rerported by:   Marc Olzheim <marcolz@stack.nl> 
MFC after:      2 weeks 



Responsible-Changed-From-To: gnn->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Sun May 29 15:33:13 GMT 2005 
Responsible-Changed-Why:  
I've committed a patch for this, so will grab ownership of it through 
the MFC process. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=78824 

From: Marc Olzheim <marcolz@stack.nl>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@FreeBSD.org,
	freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Mon, 30 May 2005 12:05:59 +0200

 On Fri, May 27, 2005 at 04:57:57PM +0200, Marc Olzheim wrote:
 > > Could you try the attached patch and see if it helps matters?  This is
 > > a slight shot in the dark but closes at least two races in the
 > > transition of socket state with respect to socket buffer state.
 > 
 > Yes! This fixes it, on the tag=RELENG_5 date=2005.03.03.00.00.00 kernel.
 > 
 > I'll try and see if it works on a recent RELENG_5 kernel as well, later.
 
 On today's RELENG_5 it works ok too, as far as I can check. :-)
 
 Marc

From: Robert Watson <rwatson@FreeBSD.org>
To: Marc Olzheim <marcolz@stack.nl>
Cc: bug-followup@FreeBSD.org, freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same
 socketpair on SMP.
Date: Mon, 30 May 2005 11:21:37 +0100 (BST)

 On Mon, 30 May 2005, Marc Olzheim wrote:
 
 > On Fri, May 27, 2005 at 04:57:57PM +0200, Marc Olzheim wrote:
 >>> Could you try the attached patch and see if it helps matters?  This is
 >>> a slight shot in the dark but closes at least two races in the
 >>> transition of socket state with respect to socket buffer state.
 >>
 >> Yes! This fixes it, on the tag=RELENG_5 date=2005.03.03.00.00.00 kernel.
 >>
 >> I'll try and see if it works on a recent RELENG_5 kernel as well, later.
 >
 > On today's RELENG_5 it works ok too, as far as I can check. :-)
 
 Great.  I'll MFC this in a week or so assuming that there are no reports 
 of problems with the patch in HEAD.  Thanks for the clear and concise bug 
 report, and sorry about taking so long to get this fixed!
 
 Robert N M Watson

From: Marc Olzheim <marcolz@stack.nl>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@FreeBSD.org,
	freebsd-stable@freebsd.org
Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Date: Fri, 10 Jun 2005 14:19:17 +0200

 On Mon, May 30, 2005 at 11:21:37AM +0100, Robert Watson wrote:
 > Great.  I'll MFC this in a week or so assuming that there are no reports 
 > of problems with the patch in HEAD.  Thanks for the clear and concise bug 
 > report, and sorry about taking so long to get this fixed!
 
 Haven't had any problems with this in the last two weekson RELENG_5.
 So the issue only remains in RELENG_5_4 now.
 
 Marc
State-Changed-From-To: patched->closed 
State-Changed-By: rwatson 
State-Changed-When: Sat Jun 11 07:54:01 GMT 2005 
State-Changed-Why:  
MFC'd to RELENG_5 as uipc_socket2.c:1.137.2.7.  No merge to RELENG_5_x 
branches currently planned. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=78824 

From: Marc Olzheim <zlo@zlo.nu>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Sven Berkvens <sven@berkvens.net>
Subject: Re: kern/78824: race condition close()ing and read()ing the same
	socketpair on SMP.
Date: Mon, 14 Mar 2005 18:48:27 +0100

 The ktrace output produced is at
 http://www.stack.nl/~marcolz/FreeBSD/kern-78824.ktrace.txt
 
 Marc
 _______________________________________________
 freebsd-bugs@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
 
>Unformatted:
