From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 11:30:01 2012 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 697981065670 for ; Tue, 3 Apr 2012 11:30:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id BFEB48FC19 for ; Tue, 3 Apr 2012 11:30:00 +0000 (UTC) Received: (qmail 25354 invoked from network); 3 Apr 2012 11:28:12 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Apr 2012 11:28:12 -0000 Message-ID: <4F7ADF5D.1060807@freebsd.org> Date: Tue, 03 Apr 2012 13:30:37 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexandre Martins References: <201204021821.37437.alexandre.martins@netasq.com> In-Reply-To: <201204021821.37437.alexandre.martins@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, bde@freebsd.org Subject: Re: Potential deadlock on mbuf 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: Tue, 03 Apr 2012 11:30:01 -0000 On 02.04.2012 18:21, Alexandre Martins wrote: > Dear, > > I have currently having troubles with a basic socket stress. > > The socket are setup to use non-blocking I/O. > > During this stress-test, the kernel is running mbuf exhaustion, the goal is to > see system limits. > > If the program make a write on a socket during this mbuf exhaustion, it become > blocked in "write" system call. The status of the process is "zonelimit" and > whole network I/O fall in timeout. > > I have found the root cause of the block : > http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 > > So, the question is : Why m_uiotombuf is called with a blocking parameter > (M_WAITOK) even if is for a non-blocking socket ? > > Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. This is a bit of an catch-22 we have here. Trouble is that when we return with EAGAIN the next select/poll cycle will tell you that this and possibly other sockets are writeable again, when in fact they are not due to kernel memory shortage. Then the application will tightly loop around the "writeable" non-writeable sockets. It's about the interaction of write with O_NONBLOCK and select/poll on the socket. Do you have any references how other OSes behave, in particular Linux? I've added bde@ as our resident standards compliance expert. Hopefully he can give us some more insight on this issue. -- Andre