Re: [patch 1/2] Validate itimer timeval from userspace

From: Eric Piel
Date: Sat Mar 18 2006 - 18:12:10 EST


18.03.2006 21:45, Jesper Juhl wrote/a écrit:
On 3/18/06, Andrew Morton <akpm@xxxxxxxx> wrote:
Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
On Sat, 2006-03-18 at 12:07 -0800, Andrew Morton wrote:

From my reading, 2.4's sys_setitimer() will normalise the incoming timeval
rather than rejecting it. And I think 2.6.13 did that too.

It would be bad of us to change this behaviour, even if that's what the
spec says we should do - because we can break existing applications.

So I think we're stuck with it - we should normalise and then accept such
timevals. And we should have a big comment explaining how we differ from
the spec, and why.
Hmm. How do you treat a negative value ?

In the same way as earlier kernels did!

Unless, of course, those kernels did something utterly insane. In that
case we'd need to have a little think.


If the change only affects buggy apps (as Thomas says), then it seems
completely obvious to me that the change should be made.

1. We'll be in compliance with the spec
2. Buggy applications will actually be helped by this by getting a
clear error instead of undefined behaviour silently hiding the fact
that they are buggy.
3. Correct applications are unaffected.
4. Applications written for an OS which respects the spec (and using this particular rule) will finally work on Linux.

Well, I'd vote for just making Linux conform to the spec as soon as someone notices a non-compliance. However, as this rule doesn't play well with a stable ABI, a "trade-off" solution could consists in:
- Keeping the old behavior for now and generate a printk() each time this code path is entered;
- Add an entry to feature-removal-schedule.txt saying Linux will start conforming to the spec next year.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/