From owner-freebsd-net Mon Oct 15 8:54: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id EB80D37B40A; Mon, 15 Oct 2001 08:54:03 -0700 (PDT) Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Oct 2001 16:53:59 +0100 (BST) To: Garrett Wollman Cc: net@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: Puzzled over sosend's handling of pre-prepared mbufs... In-Reply-To: Your message of "Thu, 27 Aug 1998 21:42:01 EDT." <199808280142.VAA11467@khavrinen.lcs.mit.edu> Date: Mon, 15 Oct 2001 16:53:58 +0100 From: Ian Dowse Message-ID: <200110151653.aa00863@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [a rather delayed response to this posting] In message <199808280142.VAA11467@khavrinen.lcs.mit.edu>, Garrett Wollman write s: >In looking over mbuf handling for TCP some more, I noticed a puzzling >omission. When sosend() is handed an mbuf chain rather than a uio, it >makes no effort to check whether the chain would actually fit within >the socket buffer limits. It simply calls pru_send() with the mbuf >chain, which -- in TCP's case -- just passes it to sbappend() also >without making any sort of check. The only client of this interface, >NFS, also makes no attempt to check the socket buffer capacity. > >Is this reasonable? I would rather see NFS obey the same buffering >model as everything else; that will make life much easier when the >underlying buffer mechanism changes. In this case, that would mean >that the process making the NFS request would get blocked rather than >``overrun'' the buffer. (I put ``overrun'' in quotation marks since >there is no physical limit on socket buffer lengths, just a >logical/administrative one.) I just came across this problem with a -current test box. When using ipfw to block an active TCP NFS mount, the NFS client ran the system out of mbufs by continuously retransmitting requests. It may be a current-specific bug that causes so many retransmits, but ignoring the socket buffer limit is a bad thing. The patch below makes the obvious change to sosend() so that it enforces the normal socket limit in the uio == NULL case also. Can anyone see any potential problems with this? I guess it is possible that NFS might need to reserve more socket space than it does currently - there is code in nfs_connect() that calls soreserve, but it is based on the vfs.nfs.bufpackets sysctl so tuning is easy. Ian Index: uipc_socket.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/kern/uipc_socket.c,v retrieving revision 1.102 diff -u -r1.102 uipc_socket.c --- uipc_socket.c 9 Oct 2001 21:40:30 -0000 1.102 +++ uipc_socket.c 15 Oct 2001 14:34:16 -0000 @@ -528,7 +528,7 @@ if ((atomic && resid > so->so_snd.sb_hiwat) || clen > so->so_snd.sb_hiwat) snderr(EMSGSIZE); - if (space < resid + clen && uio && + if (space < resid + clen && (atomic || space < so->so_snd.sb_lowat || space < clen)) { if (so->so_state & SS_NBIO) snderr(EWOULDBLOCK); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message