cvs commit: src/sys/kern uipc_debug.c uipc_sockbuf.c uipc_socket.c uipc_syscalls.c src/sys/netinet sctputil.c src/sys/sys socketvar.h

[Robert Watson]

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
>>>                         uipc_syscalls.c
>>>    sys/netinet          sctputil.c
>>>    sys/sys              socketvar.h
>>>  Log:
>>>  sblock() implements a sleep lock by interlocking SB_WANT and SB_LOCK
>>>  flags
>>>  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 
> pipe.
>
> 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
Computer Laboratory
University of Cambridge