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>