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