From owner-freebsd-arch Mon Dec 4 16:20:21 2000 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 4 16:20:18 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8DBB837B400 for ; Mon, 4 Dec 2000 16:20:18 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB50KFR23246; Mon, 4 Dec 2000 16:20:15 -0800 (PST) Date: Mon, 4 Dec 2000 16:20:15 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Bosko Milekic , arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001204162015.A8051@fw.wintelcom.net> References: <200012042352.QAA12392@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012042352.QAA12392@usr02.primenet.com>; from tlambert@primenet.com on Mon, Dec 04, 2000 at 11:52:50PM +0000 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [001204 15:54] wrote: > > > [ ... local DOS ... ] > > > > > > I really don't buy a probability defense. If a probability defense > > > were acceptable, then not checking for a NULL return, and eating > > > the panic that results is also acceptable. > > > > It's not a "probability defense." It's not a "defense." It's just a > > "don't act the worst way possible when we have an attack." And you > > haven't said at all why waiting indefinetely is better than not, > > especially in the problematic situation I brought up. > > The situation you quote is one where the allocation fails, > instead of WAITing until it can complete successfully, and > this results in the kernel function failing and state being > undone back to the point where the user space call that was > the originator of the request fails back to user space. Then > the user space code has to handle the failure. > > I maintain that the most reasonable and logical thing for the > user space program to do, on seeing this failure (ENOBUF?), > is to retry the operation. > > So it calls down again, and fails again, and you have > substituted a busy loop which crosses protection domains > twice, for a kernel sleep. This is the best case. > > The worst case is that the local DOS obtains yet more > resources when the state is backed out, and the busy > loop path in the kernel becomes shorter, due to an > earlier failure for lack of resources. > > In neither case does failing the allocation instead of > sleeping do _anything at all_ to address the root cause > of the problem, nor does the failure result in the problem > going away or being lessened. > > So I really don't see what is being accomplished by failing > the allocation, rather than sleeping, except to use up > _extra_ resources, during a time of resource starvation, to > enforce the mbuf_wait interval. [snip] Well behaved applications (read: written by me) deal with errors like ENOBUFS properly, what they do is close the socket and commence throttling connections. I would not want my process to be stuck in the kernel waiting for bufferspace that could take quite a long time get ahold of. However I can understand someone wanting a niave process not to get such errors because they may misbehave and do stupid things like busy loop or just abort entirely. Perhaps adding a per-process or per-socket or per-something flag to ask for indefinite blocking (or turn it off) would be a good idea, honestly having it one way or the other isn't very good depending on your application. I can live with the current situation so I'll leave 'fixing' this to someone who wants the indefinite blocking. Oh, and don't forget, you can't block me indefinitely if I'm writing to a non-blocking socket. In fact if M_WAIT is set I shouldn't be blocking at all on a non-blocking socket. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message