Messages in this thread | | | Date | Sat, 18 Mar 2006 22:50:30 +0100 | From | "Jesper Juhl" <> | Subject | Re: [patch 1/2] Validate itimer timeval from userspace |
| |
On 3/18/06, Andrew Morton <akpm@osdl.org> wrote: > "Jesper Juhl" <jesper.juhl@gmail.com> wrote: > > > > > It would be strange to set an alarm for 0xffffffff seconds in the future > > > but yeah, unless we can point at a reason why nobody could have ever been > > > doing that, we should turn this into permanent, documented behaviour of > > > Linux 2.6 and earlier, I'm afraid. > > > > > > > How about 0xffffffff seconds into the future being the same as 136 > > years (unless I botched the math)... That means that if any Linux > > application ever did that it's still waiting for the alarm and will be > > for at least another century... > > I'd say that makes it pretty certain that noone are doing or have been > > doing that without spotting the problem somehow - apps with such a bug > > are unlikely to be in production and actually working correctly. > > We just don't know. People do all sorts of things. > > How about this? > > $ cat /etc/my-expensive-app.conf > # > # Interval polling timer. Set this to -1 to disable > # > interval_polling_timer=-1 > > We just don't know. > True, someone might be doing something like that, but consider this as well;
an app promts the user to enter a value and passes it on, expecting to get EINVAL back if the value is wrong and has code in place to handle that (like, say, prompt the user for a different value).
That app is not buggy, but it will not work correctly because *we* are buggy.
IMO we should cater to the correctly written app and prevent it from breaking unexpectedly rather than continue to keep the buggy one working.
-- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |