On Wed, 20 Feb 2013, Andrew Morton wrote:
> On Wed, 20 Feb 2013 13:37:01 -0800
> Tejun Heo wrote:
> > hopefully with some comments. That said, if I'm grepping it right,
> > all archs define timer_t as int, so maybe we're just being paranoid.
> >
>
> Sure, it's unlikely to cause a problem in pra
On Wed, Feb 20, 2013 at 2:15 PM, Sasha Levin wrote:
> Why can the timer be negative in the first place though? Why isn't the timer
> defined as an 'unsigned int' instead of an 'int' so that all values of timer
> would be legitimate?
No idea but it's userland visible thing. No point in arguing abo
On 02/20/2013 05:12 PM, Tejun Heo wrote:
> On Wed, Feb 20, 2013 at 2:10 PM, Sasha Levin wrote:
>> I do think that if you have to resort to using something like that there's
>> something terribly wrong with the code somewhere else, and that other thing
>> should be fixed first.
>>
>> Maybe digging
On Wed, Feb 20, 2013 at 2:10 PM, Sasha Levin wrote:
> I do think that if you have to resort to using something like that there's
> something terribly wrong with the code somewhere else, and that other thing
> should be fixed first.
>
> Maybe digging into the timers code and seeing why this is need
On 02/20/2013 05:05 PM, Andrew Morton wrote:
> I wonder if we should add some generic facility to handle this:
>
> /*
> * Query whether an unsigned type is `negative' when we don't know its size
> */
> #define msb_is_set(v) { implementation goes here ;) }
>
> Maybe not justified, dunno...
I do
On Wed, Feb 20, 2013 at 02:05:51PM -0800, Andrew Morton wrote:
> Sure, it's unlikely to cause a problem in practice. Maybe five years
> from now, after idr has been cleaned up and switched to 64-bit, we've
> left a little hand grenade for someone. It would be good to
> future-safe it in some fash
On Wed, 20 Feb 2013 13:37:01 -0800
Tejun Heo wrote:
> Hello, Andrew.
>
> On Wed, Feb 20, 2013 at 01:23:00PM -0800, Andrew Morton wrote:
> > > @@ -637,6 +637,9 @@ static struct k_itimer *__lock_timer(timer_t
> > > timer_id, unsigned long *flags)
> > > {
> > > struct k_itimer *timr;
> > >
>
On Wed, Feb 20, 2013 at 10:47:12PM +0100, Thomas Gleixner wrote:
> Missed that, but good to know that this insanity is going to be gone
> soon.
Yeah, idr at least shouldn't be insane interface-wise. Its
implementation still makes me want to drive pencils into my eyes and
ida still needs some love
On Wed, 20 Feb 2013, Tejun Heo wrote:
> Hey, Thomas.
>
> On Wed, Feb 20, 2013 at 10:38:36PM +0100, Thomas Gleixner wrote:
> > I can grumpily accept the patch below as a quick hack fix, which can
> > go to stable as well, but not with such a patently misleading
> > changelog.
> >
> > The changelo
Hey, Thomas.
On Wed, Feb 20, 2013 at 10:38:36PM +0100, Thomas Gleixner wrote:
> I can grumpily accept the patch below as a quick hack fix, which can
> go to stable as well, but not with such a patently misleading
> changelog.
>
> The changelog wants to document, that this is not a proper fix at a
On Wed, 20 Feb 2013, Tejun Heo wrote:
> Recent idr updates make idr_find() trigger WARN_ON_ONCE() before
> returning NULL when a negative ID is specified. Apparently,
> posix-timer::__lock_timer() was depending on idr_find() returning NULL
> on negative ID, thus triggering the new WARN_ON_ONCE().
Hello, Andrew.
On Wed, Feb 20, 2013 at 01:23:00PM -0800, Andrew Morton wrote:
> > @@ -637,6 +637,9 @@ static struct k_itimer *__lock_timer(timer_t timer_id,
> > unsigned long *flags)
> > {
> > struct k_itimer *timr;
> >
> > + if ((int)timer_id < 0)
> > + return NULL;
> > +
> >
On 02/20/2013 04:01 PM, Tejun Heo wrote:
> Recent idr updates make idr_find() trigger WARN_ON_ONCE() before
> returning NULL when a negative ID is specified. Apparently,
> posix-timer::__lock_timer() was depending on idr_find() returning NULL
> on negative ID, thus triggering the new WARN_ON_ONCE(
On Wed, 20 Feb 2013 13:01:16 -0800
Tejun Heo wrote:
> Recent idr updates make idr_find() trigger WARN_ON_ONCE() before
> returning NULL when a negative ID is specified. Apparently,
> posix-timer::__lock_timer() was depending on idr_find() returning NULL
> on negative ID, thus triggering the new
14 matches
Mail list logo
