Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 May 2007 12:25:35 -0400
From:      Randall Stewart <rrs@cisco.com>
To:        Alfred Perlstein <alfred@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: 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
Message-ID:  <463A0CFF.60600@cisco.com>
In-Reply-To: <20070503160413.GL67243@elvis.mu.org>
References:  <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com> <20070503160413.GL67243@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
> * Randall Stewart <rrs@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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463A0CFF.60600>