[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020810071031n39c27966ubfafd86e5542ea75@mail.gmail.com>
Date: Tue, 7 Oct 2008 20:31:16 +0300
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Matt Mackall" <mpm@...enic.com>
Cc: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
"Christoph Lameter" <cl@...ux-foundation.org>,
linux-mm <linux-mm@...ck.org>,
"Nick Piggin" <nickpiggin@...oo.com.au>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Ingo Molnar" <mingo@...e.hu>,
linux-kernel <linux-kernel@...r.kernel.org>,
akpm <akpm@...uxfoundation.org>
Subject: Re: [BUG] SLOB's krealloc() seems bust
Hi Matt,
On Tue, Oct 7, 2008 at 8:13 PM, Matt Mackall <mpm@...enic.com> wrote:
>> > @@ -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?
Yeah, I was referring to the second subtraction. Looking at
slob_page_alloc(), for example, we compare the return value of
slob_units() to SLOB_UNITS(size), so I don't think we count the header
in ->units. I mean, we ought to be seeing the subtraction elsewhere in
the code as well, no?
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists