Date: Sun, 3 Dec 2000 22:18:26 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bmilekic@technokratis.com (Bosko Milekic) Cc: tlambert@primenet.com (Terry Lambert), dg@root.com, gallatin@cs.duke.edu (Andrew Gallatin), ken@kdm.org (Kenneth D. Merry), arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <200012032218.PAA03289@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.21.0012031610070.98081-100000@jehovah.technokratis.com> from "Bosko Milekic" at Dec 03, 2000 04:26:26 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think the idea that the M_WAIT flag should be broken so that > > it can be safely used in interrupt mode is dumb. > > I'm not sure I understand what you're putting forward with the above > comment, specifically what you're referring to when you say "broken." > Are you trying to say that "M_WAIT is broken because it doesn't wait > forever?" If that's what you're trying to say, the explanation is simple. > If you "wait indefinetely," or spin as you're doing above, then what > you're doing is pretty much useless. Let me explain why and how you can > test my hypothesis without changing a single line of code. [ ... 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. The problem with this theory is that "have the the [non-offending] process return from the kernel and deal with the temporary failure" presumes that there is a correct way to work around the failure in user space. I would maintain that the failure would be persistant, since this does nothing to silence the DOS attack, and there is nothing that a user space program can do, except to retry, and get all the way down the code path to the same place that it was before. It seems to me that this is just a case of how big you want to make your retry loop, not one of whether or not there will be a retry loop. As an example of a user space DOS that can result in this, if you have a FreeBSD machine which has an interface that is the default route to the network, and a second interface that is the local network, and the interface which is the default route is "down" (as in a PPP interface with the modem turned off), you can start a "ping" of an external machine (e.g. 16.1.0.2) which will eventually consume all of the mbufs with ICMP echo datagrams which can't be transmitted. At this point, machines on the local network cannot log into the gateway machine over the network to correct the problem. I would argue that this level of congestion should be proactively prohibited from occurring in the first place; the most likely way to do this correctly is to start "dropping" the oldest datagrams, NOT returning "NULL" to allocations made on behalf od telnetd or sshd from the local interface. In other words, if this is a fear-response for a local DOS, then there are better ways of achieving the same result, without still locking up networking. --- > Basically, what I'm telling you is: M_WAIT behavior is not broken in > FreeBSD, it is entirely tunable and it is better, in the general case, to > NOT have M_WAIT mean 'wait indefinetely.' As a general bone of contention, if the thing _doesn't_ wait, it shouldn't be called M_WAIT, it should be called M_TRY_HARDER or something that indicates that the default behaviour has been altered, but in fact the routine will not be waiting around until it is successful, like all of the other _WAIT flags imply. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200012032218.PAA03289>