Date: Thu, 3 May 2007 18:08:16 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-src@FreeBSD.org, Randall Stewart <rrs@cisco.com>, 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: <20070503180707.D30997@fledge.watson.org> 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
On Thu, 3 May 2007, 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? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070503180707.D30997>