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

[Thomas Gleixner <tglx@linutronix.de>]

On Sat, 2006-03-18 at 20:10 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > According to the specification the timeval must be validated and an 
> > errorcode -EINVAL returned in case the timeval is not in canonical 
> > form. Before the hrtimer merge this was silently ignored by the 
> > timeval to jiffies conversion. The validation is done inside 
> > do_setitimer so all callers are catched.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> ok - bad (invalid) timevals were thus randomly interpreted? I agree that 
> even though this is new behavior, it is much better to return -EINVAL 
> than to behave randomly. OTOH, since 2.6.15 and earlier did this too, is 
> there any urgency to apply this to 2.6.16?

Sorry, I explained it badly.

The negative timer values were converted to MAX_JIFFIES_PER_LONG
timeouts and intervals.

The hrtimer code expects canonical values for the start time and the
interval. The random non canonical values should not do any damage, but
the normalizing routines might loop for a while. The negative start time
will be treated as expired and negative intervals are adjusted to
resolution (jiffie) in the hrtimer_forward code.

So the behaviour is different anyway, but I prefer the clear -EINVAL to
randomness.

	tglx