Date: Thu, 31 Jan 2008 08:22:25 +0000 (UTC) From: Robert Watson <rwatson@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sys socketvar.h src/sys/kern uipc_sockbuf.c uipc_socket.c uipc_syscalls.c src/sys/netinet sctp_input.c sctp_peeloff.c sctputil.c Message-ID: <200801310822.m0V8MPBV083517@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
rwatson 2008-01-31 08:22:25 UTC
FreeBSD src repository
Modified files:
sys/sys socketvar.h
sys/kern uipc_sockbuf.c uipc_socket.c
uipc_syscalls.c
sys/netinet sctp_input.c sctp_peeloff.c sctputil.c
Log:
Correct two problems relating to sorflush(), which is called to flush
read socket buffers in shutdown() and close():
- Call socantrcvmore() before sblock() to dislodge any threads that
might be sleeping (potentially indefinitely) while holding sblock(),
such as a thread blocked in recv().
- Flag the sblock() call as non-interruptible so that a signal
delivered to the thread calling sorflush() doesn't cause sblock() to
fail. The sblock() is required to ensure that all other socket
consumer threads have, in fact, left, and do not enter, the socket
buffer until we're done flushin it.
To implement the latter, change the 'flags' argument to sblock() to
accept two flags, SBL_WAIT and SBL_NOINTR, rather than one M_WAITOK
flag. When SBL_NOINTR is set, it forces a non-interruptible sx
acquisition, regardless of the setting of the disposition of SB_NOINTR
on the socket buffer; without this change it would be possible for
another thread to clear SB_NOINTR between when the socket buffer mutex
is released and sblock() is invoked.
Reviewed by: bz, kmacy
Reported by: Jos Backus <jos at catnook dot com>
Revision Changes Path
1.175 +6 -2 src/sys/kern/uipc_sockbuf.c
1.304 +11 -5 src/sys/kern/uipc_socket.c
1.264 +7 -2 src/sys/kern/uipc_syscalls.c
1.67 +2 -1 src/sys/netinet/sctp_input.c
1.17 +2 -2 src/sys/netinet/sctp_peeloff.c
1.73 +1 -1 src/sys/netinet/sctputil.c
1.161 +7 -0 src/sys/sys/socketvar.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801310822.m0V8MPBV083517>