Messages in this thread | | | Subject | Re: [BUG] SLOB's krealloc() seems bust | From | Matt Mackall <> | Date | Tue, 07 Oct 2008 12:13:39 -0500 |
| |
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.
| |