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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2006-03-18 at 20:10 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <[email protected]> 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 <[email protected]>
> 
> 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


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux