From owner-freebsd-net@FreeBSD.ORG Thu Jan 23 18:27:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 563DABE9; Thu, 23 Jan 2014 18:27:00 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 035C71ACB; Thu, 23 Jan 2014 18:26:59 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id c9so3002720qcz.27 for ; Thu, 23 Jan 2014 10:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TevHMeTD5l9crIcsMhaaMZS6c7mh4zOAOqiN1VIk/yU=; b=OCVnbv/98unvDkk/j0BGFfLqFteK1mLcX4WQxrheh8su/jNXSj5zmCxce4CpezmTVS Y7DfV6k0JwS6WwFP5QmofWgmq6W6fBnxhWDikpRX79EtR9cUj6yTrKNbbsTMPwZl3LR/ auqVRO3Os0Bh8QrHUMi1mJOdjoHBrBI2nsNBHFnLdDAy8yb7bRDSCq5pV+3p1ezLq142 5r+JP5hOgvTpL8sEyIRxZV4zwPrxiuckd5dSTo35NbsSEbNleUVEJLy2lPzp3BT6Obmw JpZ+JRTDxqxAvzjyYAJ19BNnQuZ1aINK4Ob+JiuZ4U8N9YH16jEhR9vwRWHl5p9EXhvY +dFQ== MIME-Version: 1.0 X-Received: by 10.224.89.71 with SMTP id d7mr14080640qam.26.1390501619094; Thu, 23 Jan 2014 10:26:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 23 Jan 2014 10:26:59 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 10:26:59 -0800 X-Google-Sender-Auth: R8CGHhA_3fv-1emt5RHLqVrIWjU Message-ID: Subject: Re: kern/185813: SOCK_SEQPACKET AF_UNIX sockets with asymmetrical buffers drop packets From: Adrian Chadd To: Alan Somers Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:27:00 -0000 Well, shouldn't we fix the API/code so it doesn't drop packets, regardless of the sensibility or non-sensibility of different transmit/receive buffer sizes? -a On 23 January 2014 10:02, Alan Somers wrote: > There is a buffer space calculation bug in the send path for > SOCK_SEQPACKET AF_UNIX sockets. The result is that, if the sending > and receiving buffer sizes are different, the kernel will drop > messages and leak mbufs. A more detailed description is available in > the PR. > > The labyrinthine nature of the networking code makes it difficult to > directly fix the space calculation. It's especially hard due to the > optimization that AF_UNIX sockets have only a single socket buffer. > As implemented, they store data in the receiving sockbuf, but use the > transmitting sockbuf for space calculations. That's even true of > SOCK_STREAM sockets. They only work due to an accident; they don't > end up doing the same space calculation that trips up SOCK_SEQPACKET > sockets. > > Instead, I propose modifying the kernel to force an AF_UNIX socket > pair's buffers to always have the same size. That is, if you call > setsockopt(s, SOL_SOCKET, SO_SNDBUF, whatever, whatever), the kernel > will adjust both s's send buffer and the connected socket's receive > buffer. This solution also solves another annoying problem: currently > there is no way for a program to effectively change the size of its > receiving buffers. If you call setsockopt(s, SOL_SOCKET, SO_RCVBUF, > whatever, whatever) on an AF_UNIX socket, it will have no effect on > how packets are actually handled. > > The attached patch implements my suggestion for setsockopt. It's > obviously not perfect; it doesn't handle the case where you call > setsockopt() before connect() and it introduces an unfortunate > #include, but it's a working proof of concept. With this patch, the > recently added ATF test case > sys/kern/unix_seqpacket_test:pipe_simulator_128k_8k passes. Does this > look like the correct approach? > > > Index: uipc_socket.c > =================================================================== > --- uipc_socket.c (revision 261055) > +++ uipc_socket.c (working copy) > @@ -133,6 +133,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -2382,6 +2384,8 @@ > int > sosetopt(struct socket *so, struct sockopt *sopt) > { > + struct socket* so2; > + struct unpcb *unpcb, *unpcb2; > int error, optval; > struct linger l; > struct timeval tv; > @@ -2503,6 +2507,32 @@ > } > (sopt->sopt_name == SO_SNDBUF ? &so->so_snd : > &so->so_rcv)->sb_flags &= ~SB_AUTOSIZE; > + if (so->so_proto->pr_domain->dom_family != > + PF_LOCAL || > + so->so_type != SOCK_SEQPACKET) > + break; > + /* > + * For unix domain seqpacket sockets, we set the > + * bufsize on both ends of the socket. PR > + * kern/185813 > + */ > + unpcb = (struct unpcb*)(so->so_pcb); > + if (NULL == unpcb) > + break; /* Shouldn't ever happen */ > + unpcb2 = unpcb->unp_conn; > + if (NULL == unpcb2) > + break; /* For unconnected sockets */ > + so2 = unpcb2->unp_socket; > + if (NULL == so2) > + break; /* Shouldn't ever happen? */ > + if (sbreserve(sopt->sopt_name == SO_SNDBUF ? > + &so2->so_rcv : &so2->so_snd, (u_long)optval, > + so, curthread) == 0) { > + error = ENOBUFS; > + goto bad; > + } > + (sopt->sopt_name == SO_SNDBUF ? &so2->so_rcv : > + &so2->so_snd)->sb_flags &= ~SB_AUTOSIZE; > break; > > /* > > > -Alan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"