Date: Sun, 03 Dec 2000 18:25:36 -0500 (EST) From: Bosko Milekic <bmilekic@technokratis.com> To: Terry Lambert <tlambert@primenet.com> Cc: arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <Pine.BSF.4.21.0012031808540.98531-100000@jehovah.technokratis.com> In-Reply-To: <200012032218.PAA03289@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Dec 2000, Terry Lambert wrote: > > > 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. 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 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. No, it doesn't. But it's better for the process to sleep in user space than to be INDEFINETELY stuck in the kernel. And, in the case of an attack, it _will_ be indefinetely stuck. > 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. Right. It's not a preventive measure. But, it's much better to have it act in this manner than wait indefinetely "in the case of." > 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. The retry loop is _useless_. You drop the mutex and lose priority in the wait queue when you return from m_get(). Calling again makes your chances of getting an mbuf in a shortage even less probable. If you want that behavior, just tweak your kern.ipc.mbuf_wait. [...] > 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. This is really a great block of theory. I only wish that people with such a passion to argue the methods would work in actually implementing them. > 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. It's not. It never was. It never will be. It's just better than waiting indefinetely. It still provides you with the ability to wait indefinetely, though, if you are incapable of understanding why it's better not to. > > 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. It _does_ wait, and I disagree. By that logic, why not rename all the _WAITs with _WAIT_INDEF? If you're curious about what M_WAIT does, you can either read the code (hey, it is free!) or read the mbuf(9) man page (now available in -CURRENT). > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Regards, Bosko Milekic bmilekic@technokratis.com 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?Pine.BSF.4.21.0012031808540.98531-100000>