From: Andrew Morton <akpm@linux-foundation.org>
To: Tejun Heo <tj@kernel.org>
Cc: Sasha Levin <sasha.levin@oracle.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] posix-timer: don't call idr_find() w/ negative ID
Date: Wed, 20 Feb 2013 14:05:51 -0800 [thread overview]
Message-ID: <20130220140551.8017e795.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130220213701.GE3570@htj.dyndns.org>
On Wed, 20 Feb 2013 13:37:01 -0800
Tejun Heo <tj@kernel.org> 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;
> > >
> > > + if ((int)timer_id < 0)
> > > + return NULL;
> > > +
> > > rcu_read_lock();
> > > timr = idr_find(&posix_timers_id, (int)timer_id);
> > > if (timr) {
> >
> > This is a bit risky - if some arch defines timer_t to be a u64 then we
> > will incorrectly treat 0x0000 0001 ffff ffff as a negative number.
> > (That's a lot of timers!)
> >
> > A fancy way of avoiding this is
> >
> > if (timer_id & ((typeof timer_id)1 << (sizeof(timer_id) - 1)))
> >
> > (approximately ;))
> >
> > But I think casting to (long) should be good enough?
>
> Sans WARN_ON_ONCE(), the code would behave the same as before, which
> in turn, from what I can tell, is the behavior the code intended to
> implement before idr_alloc() conversion.
>
> If timer_id is being allocated from idr, a valid id can never go over
> INT_MAX and returning NULL for any ID above that is the correct
> behavior, I think. If timer_t is larger than int, both (int) and
> (long) castings wouldn't be useful. Both will miss (1LU << 33) + 1
> and idr_find() will end up looking for 1.
>
> If we want to be strict, we would have to do, I think,
>
> if ((unsigned long long)timer_t > INT_MAX)
>
> 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 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 fashion.
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...
next prev parent reply other threads:[~2013-02-20 22:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 18:44 [PATCH] idr: prevent NULL deref on lookups before insertions Sasha Levin
2013-02-20 18:45 ` Tejun Heo
2013-02-20 19:23 ` Sasha Levin
2013-02-20 21:01 ` [PATCH] posix-timer: don't call idr_find() w/ negative ID Tejun Heo
2013-02-20 21:23 ` Andrew Morton
2013-02-20 21:37 ` Tejun Heo
2013-02-20 22:05 ` Andrew Morton [this message]
2013-02-20 22:08 ` Tejun Heo
2013-02-20 22:40 ` [PATCH] posix-timer: don't call idr_find() w/ out-of-range ID Tejun Heo
2013-02-20 23:01 ` Thomas Gleixner
2013-02-20 23:07 ` Tejun Heo
2013-02-20 23:11 ` Thomas Gleixner
2013-02-20 23:24 ` [PATCH UPDATED] " Tejun Heo
2013-02-20 23:35 ` [PATCH] idr: explain WARN_ON_ONCE() on negative IDs " Tejun Heo
2013-02-21 9:10 ` Thomas Gleixner
2013-02-21 16:38 ` [tip:timers/urgent] posix-timer: Don't call idr_find() with " tip-bot for Tejun Heo
2013-02-20 22:10 ` [PATCH] posix-timer: don't call idr_find() w/ negative ID Sasha Levin
2013-02-20 22:12 ` Tejun Heo
2013-02-20 22:15 ` Sasha Levin
2013-02-20 22:20 ` Tejun Heo
2013-02-20 23:09 ` Thomas Gleixner
2013-02-20 21:32 ` Sasha Levin
2013-02-20 21:38 ` Thomas Gleixner
2013-02-20 21:43 ` Tejun Heo
2013-02-20 21:47 ` Thomas Gleixner
2013-02-20 21:50 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130220140551.8017e795.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sasha.levin@oracle.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.