From owner-freebsd-current@FreeBSD.ORG Thu Aug 27 14:16:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56B3C106568E; Thu, 27 Aug 2009 14:16:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 284928FC3A; Thu, 27 Aug 2009 14:16:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CF35A46B2A; Thu, 27 Aug 2009 10:16:47 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CE4F78A02D; Thu, 27 Aug 2009 10:16:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 27 Aug 2009 08:27:03 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908270827.03670.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 27 Aug 2009 10:16:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet , Robert Watson Subject: Re: LOR: so_snd_sx vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:16:48 -0000 On Thursday 27 August 2009 7:34:03 am Robert Watson wrote: > > On Thu, 27 Aug 2009, pluknet wrote: > > > This is a FreeBSD 9.0-CURRENT i386. The LOR was caught via stress2 suite. I > > guess sblock() (uipc_sockbuf.c:148 here) was called from sosend_generic() > > (which is at line uipc_socket.c:1436). > > This is probably the "right" order, as opposed to the wrong one. Could you > look at witness's dynamic order information in DDB or via sysctl and see what > the "other" order is? Alternatively, hard-code this harder in subr_witness > and then the other order will be reported instead. I suspect the NFS client will perform socket I/O while holding a buffer which would give the other order. I'm not sure you can trigger a deadlock as a socket used for NFS is never read/written to directly by userland however. -- John Baldwin