From owner-cvs-all@FreeBSD.ORG Thu May 3 16:23:12 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 8145516A403; Thu, 3 May 2007 16:23:12 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 4371A13C43E; Thu, 3 May 2007 16:23:12 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 May 2007 09:23:12 -0700 X-IronPort-AV: i="4.14,486,1170662400"; d="scan'208"; a="418300332:sNHT59738470" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l43GNBbt002683; Thu, 3 May 2007 09:23:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l43GNBA8011323; Thu, 3 May 2007 16:23:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 09:23:11 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 09:23:11 -0700 Message-ID: <463A0CFF.60600@cisco.com> Date: Thu, 03 May 2007 12:25:35 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Alfred Perlstein , Robert Watson References: <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com> <20070503160413.GL67243@elvis.mu.org> In-Reply-To: <20070503160413.GL67243@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 16:23:11.0284 (UTC) FILETIME=[57A11740:01C78D9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1962; t=1178209391; x=1179073391; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20cvs=20commit=3A=20src/sys/kern=20uipc_debug.c=20uipc_ sockbuf.c=20uipc_socket.c=0A=20uipc_syscalls.c=20src/sys/netinet=20sctputi l.c=20src/sys/sys=20socketvar.h |Sender:=20; bh=+FT/a8yXnR8d/yTZ+KpDVClJmqc3YLxtiYRJF4Zd+cs=; b=Ni4kyOoJKsh5sDZUThlXWwN9z+wEcqch/pDoIxKDGUUblAFjx2CeEoeaVWGRubaqRtvcJXHD 4RxlJh9YA3GvoN0XoRy1FsR03A4epNmb8Et2BPj+A/chv92Fv/TjNvSg; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); 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 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:23:12 -0000 Alfred Perlstein wrote: > * 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 > 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 803-317-4952 (cell)