Re: [PATCH] posix-timer: don't call idr_find() w/ out-of-range ID

On Wed, 20 Feb 2013, Tejun Heo wrote: > Hello, Thomas. > > On Thu, Feb 21, 2013 at 12:01:07AM +0100, Thomas Gleixner wrote: > > idr_find() should simply return NULL, if "id < 0". Is it that hard? > > It already does but w/ WARN_ON_ONCE(). The WARN_ON_ONCE() is there > mostly as a transitional p

Re: [PATCH] posix-timer: don't call idr_find() w/ out-of-range ID

Hello, Thomas. On Thu, Feb 21, 2013 at 12:01:07AM +0100, Thomas Gleixner wrote: > idr_find() should simply return NULL, if "id < 0". Is it that hard? It already does but w/ WARN_ON_ONCE(). The WARN_ON_ONCE() is there mostly as a transitional precaution. As the previous idr_find() behavior was e

Re: [PATCH] posix-timer: don't call idr_find() w/ out-of-range ID

On Wed, 20 Feb 2013, Tejun Heo wrote: > When idr_find() is fed a negative ID, it used to look up the ID > ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and > move left MAX_IDR_* into idr.c") patch, and triggers WARN_ON_ONCE() > after it. > > __lock_timer() feeds timer_id from use

[PATCH] posix-timer: don't call idr_find() w/ out-of-range ID

When idr_find() is fed a negative ID, it used to look up the ID ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c") patch, and triggers WARN_ON_ONCE() after it. __lock_timer() feeds timer_id from userland directly to idr_find() without sanitizing it