lkml.org 
[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] SLOB's krealloc() seems bust
From
Date

On Tue, 2008-10-07 at 19:57 +0300, Pekka Enberg wrote:
> Hi Matt,
>
> On Tue, Oct 7, 2008 at 7:37 PM, Matt Mackall <mpm@selenic.com> wrote:
> > SLOB: fix bogus ksize calculation
> >
> > SLOB's ksize calculation was braindamaged and generally harmlessly
> > underreported the allocation size. But for very small buffers, it could
> > in fact overreport them, leading code depending on krealloc to overrun
> > the allocation and trample other data.
> >
> > Signed-off-by: Matt Mackall <mpm@selenic.com>
> > Tested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >
> > diff -r 5e32b09a1b2b mm/slob.c
> > --- a/mm/slob.c Fri Oct 03 14:04:43 2008 -0500
> > +++ b/mm/slob.c Tue Oct 07 11:27:47 2008 -0500
> > @@ -515,7 +515,7 @@
> >
> > sp = (struct slob_page *)virt_to_page(block);
> > if (slob_page(sp))
> > - return ((slob_t *)block - 1)->units + SLOB_UNIT;
> > + return (((slob_t *)block - 1)->units - 1) * SLOB_UNIT;
>
> Hmm. I don't understand why we do the "minus one" thing here. Aren't
> we underestimating the size now?

The first -1 takes us to the object header in front of the object
pointer. The second -1 subtracts out the size of the header.

But it's entirely possible I'm off by one, so I'll double-check. Nick?

--
Mathematics is the supreme nostalgia of our time.



\
 
 \ /
  Last update: 2008-10-07 19:19    [W:0.034 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site