Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Oct 2001 16:53:58 +0100
From:      Ian Dowse <iedowse@maths.tcd.ie>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        net@FreeBSD.ORG, peter@FreeBSD.ORG
Subject:   Re: Puzzled over sosend's handling of pre-prepared mbufs... 
Message-ID:   <200110151653.aa00863@salmon.maths.tcd.ie>
In-Reply-To: Your message of "Thu, 27 Aug 1998 21:42:01 EDT." <199808280142.VAA11467@khavrinen.lcs.mit.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help

[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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200110151653.aa00863>