Date: Mon, 4 Dec 2000 16:20:15 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001204162015.A8051@fw.wintelcom.net> In-Reply-To: <200012042352.QAA12392@usr02.primenet.com>; from tlambert@primenet.com on Mon, Dec 04, 2000 at 11:52:50PM %2B0000 References: <Pine.BSF.4.21.0012031808540.98531-100000@jehovah.technokratis.com> <200012042352.QAA12392@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001204162015.A8051>