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

Randall Stewart rrs at cisco.com
Thu May 3 16:23:12 UTC 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?
> 
> -Alfred
> 
Well.. I can't.. I just did a small part of this..

I did not look at the code that Robert did on the
socket buffer side of things.. I only did the sblock() stuff
that Robert wanted in the sctputil.c

Now looking at the sx_lock code (for the first time).. I too
don't see how it is interrupted.. but  I am sure Robert
thought of this.. I am chasing another SCTP bug right now
and have a huge integration project going on as well ... so
I don't have time to look at this..

Robert, what do you think of this scenario?

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)


More information about the cvs-src mailing list