From owner-freebsd-net@FreeBSD.ORG Fri May 3 00:00:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82E6744A for ; Fri, 3 May 2013 00:00:25 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF9F1CE2 for ; Fri, 3 May 2013 00:00:24 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id y10so1146030wgg.20 for ; Thu, 02 May 2013 17:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Isqf5lGTNSXTCsNkgvqIK/dCZ8ZG20o/OrtwmrPSfE8=; b=HZHpDQ4GkOS5lJQ9HzD8WwijtbStR7kGoPrxQqvgOuQzrSvPdh+yz0N8gWrgCVEOdv 4mo0r3eTzkeKvxeliFqQIVJvsp8eCMt4Z98fT8/fOCQW9Sla++ZH7gHau0VbzeMMWyCZ HJSz4lTKUnOB7Ad+AIXO9VBwBeOTTfpUUuMR/0vgMW3qY5E+b6ZPJHbiI7sV++wk6Dau aNhinOYXbYixy6zSCNRIdfvhjBKfPlwHxPNxJRmLfCkj/fmNZQdXborA3xC/DsQPwfa+ tEKoFDPBspQj6G6Gh4M6sTyoFRwmt3sM0On0OF4OpfeKLcdpe8y4Atypiv76nPueVhn/ 57BA== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr10852405wjb.29.1367539223875; Thu, 02 May 2013 17:00:23 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Thu, 2 May 2013 17:00:23 -0700 (PDT) In-Reply-To: <51827DAA.2020009@vangyzen.net> References: <5181ECDF.1040905@mu.org> <51827DAA.2020009@vangyzen.net> Date: Thu, 2 May 2013 17:00:23 -0700 Message-ID: Subject: Re: Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire From: Richard Sharpe To: Eric van Gyzen Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 00:00:25 -0000 On Thu, May 2, 2013 at 7:52 AM, Eric van Gyzen wrote: > On 05/02/2013 08:48, Richard Sharpe wrote: >> On Wed, May 1, 2013 at 9:34 PM, Alfred Perlstein wrote: >>> On 5/1/13 8:03 PM, Richard Sharpe wrote: >>>> Hi folks, >>>> >>>> I am checking to see if there are any known bugs with respect to this >>>> in FreeBSD 8.0. >>>> >>>> Situation is that Samba 3.6.6 uses writev to a non-blocking socket to >>>> get the SMB2 requests on the wire. >>>> >>>> Intermittently, we see the writev return EINVAL even though the data >>>> has gotten on the wire. This I have verified by grabbing a capture and >>>> comparing the SMB Sequence number in the last outgoing packet on the >>>> wire vs the in-memory contents when we get EINVAL. >>>> >>>> Sometimes it occurs on a four-element IOVEC, sometimes we get EAGAIN >>>> on the four-element IOVEC and then we get EINVAL when retrying on a >>>> smaller IOVEC. >>>> >>>> Where should I look to check if there is some path where this might be >>>> happening? Is this even the correct mailing list? >>>> >>> What does the iovec look like when you get EINVAL? Can you sanity check >>> it? Is there anything special about it? (zero length vecs?) >>> >>> I think there are a few "maxvals" that if overrun cause EINVAL to be >>> returned. example is if your iovec is somehow huge or has many, many >>> elements. >> Can anyone tell me the call graph down to the TCP code? >> > > writev kern/sys_generic.c > kern_writev > dofilewrite > fo_write in sys/file.h > soo_write in kern/sys_socket.c > sosend in kern/uipc_socket.c > sosend_generic > tcp_usr_send in netinet/tcp_usrreq.c Is there a tool that generates call graphs? I have been able to demonstrate that I am getting EINVAL returned from writev kern/sys_generic.c, kern_writev, dofilewrite and soo_write, but when I add printfs to sosend/sosend_generic it becomes very hard to provoke this problem. I wonder if the compiler is generating code that allows some functions to leave variables in registers but they are not treated as volatile. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE)