From owner-cvs-all@FreeBSD.ORG Thu May 3 16:03:38 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C53316A410; Thu, 3 May 2007 16:03:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 633D913C489; Thu, 3 May 2007 16:03:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 560381A4DA3; Thu, 3 May 2007 09:04:13 -0700 (PDT) Date: Thu, 3 May 2007 09:04:13 -0700 From: Alfred Perlstein To: Randall Stewart Message-ID: <20070503160413.GL67243@elvis.mu.org> References: <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <463A0198.3040507@cisco.com> User-Agent: Mutt/1.4.2.2i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson , 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 16:03:38 -0000 * Randall Stewart [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