Re: + expose-range-checking-functions-from-arch-specific.patch added to -mm tree

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 11 Apr 2007 12:19:10 +1000 Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Tue, 2007-04-10 at 11:17 +0100, David Howells wrote:
> > akpm@linux-foundation.org wrote:
> > 
> > > + * @limit: the first invalid value
> > 
> > If this is the case, ...
> > 
> > > + *
> > > + * Like val + len > limit, except with overflow checking.
> > > + */
> > > +static inline bool val_outside(unsigned long val, unsigned long len,
> > > +			       unsigned long limit)
> > > +
> > > +{
> > > +	return val + len > limit || val + len < val;
> > 
> > ... then shouldn't that be "val + len >= limit"?
> 
> You're the second one to ask this.  I'm pretty sure it's still right
> (and it's what the old code used to do).
> 
> Consider the case where limit is 0xC0000000, val is 0xBFFFFFFF and len
> is 1.
> 

I probably shouldn't look at this after a glass of red, but otoh, perhaps
that's a good way of ensuring that we have a built-in margin.


I find this function incomprehensible.  I'd just avoid using the sorry
thing, personally.


To me, "val_outside" means "true if the value is outside":

bool val_outside(val, start, len)
{
	return val < start || val > (start+len-1);
}

that's what my function does.  I don't have a clue what yours does.

For starters, wtf is a "limit"?  A length?  Or an offset relative to "len"?
And wtf is "len" anyway?  Absolute?  Relative?

<reworks it>

	return val > (limit - len) || val < (val - len);

nope, that didn't help.



The consequences of people getting this wrong are oopses, memory
corruption, root holes and other such pleasantry, in rare (or deliberately
invoked) circumstances.  Can we try to make it easier for them?