Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 - 1.145
+++ uipc_socket2.c 27 May 2005 11:34:03 -
@@ -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);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 pgpoDpKx9OUzA.pgp Description: PGP signature
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 pgpZJsFY2SOBa.pgp Description: PGP signature
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP.
Is this going to be fixed before 5.4 ? It still breaks on today's 5.4-STABLE. Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
