cvs commit: src/sys/kern uipc_debug.c uipc_sockbuf.c
uipc_syscalls.c src/sys/netinet sctputil.c src/sys/sys socketvar.h
rwatson at FreeBSD.org
Thu May 3 17:08:17 UTC 2007
On Thu, 3 May 2007, Alfred Perlstein wrote:
> * Randall Stewart <rrs at cisco.com> [070503 08:35] wrote:
>> Robert Watson wrote:
>>> rwatson 2007-05-03 14:42:42 UTC
>>> FreeBSD src repository
>>> Modified files:
>>> sys/kern uipc_debug.c uipc_sockbuf.c uipc_socket.c
>>> sys/netinet sctputil.c
>>> sys/sys socketvar.h
>>> sblock() implements a sleep lock by interlocking SB_WANT and SB_LOCK
>>> on each socket buffer with the socket buffer's mutex. This sleep lock is
>>> used to serialize I/O on sockets in order to prevent I/O interlacing.
> I'm looking at the diff... it looks like you dropped signal handling from
> sblock? Is that true and if so was that intentional?
> I'm worried that the following situation can happen:
> process A: init large write to socket.
> process A: gets sblock
> process A: fills socketbuffer
> process A: waits for space.
> process B: tries to write to socket
> Now process B is in an uninterruptable wait until the remote side drains the
> The same problem might happen (even easier to reproduce) when there are
> multiple readers.
> Of course this all depends on me missing something.
> Can you explain?
You are entirely right -- I'm not sure how I missed the SB_NOINTR flag
semantics in sb_lock(), but apparently I did. I'm talking to Attilio right
now about adding an interruptible version of the sleeping exclusive lock
acquire and will follow up on this shortly. Thanks for pointing this out!
Robert N M Watson
University of Cambridge
More information about the cvs-all