On Aug 18 2007 01:40, Thomas Gleixner wrote:
>
>Do we really ?
>
>If yes, who invented this 1980s reminiscence, where you got valid
>pointers for malloc(0) ?
>
>This is completely stupid. You do not go into a bar and order an empty
>glass, just because you might eventually become thirsty later.
On 8/18/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> If yes, who invented this 1980s reminiscence, where you got valid
> pointers for malloc(0) ?
Well, kmalloc(0) has always been legal and traditionally returned a
pointer to a smallest non-zero sized object. We did try to make
kmalloc(0)
On 8/18/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
If yes, who invented this 1980s reminiscence, where you got valid
pointers for malloc(0) ?
Well, kmalloc(0) has always been legal and traditionally returned a
pointer to a smallest non-zero sized object. We did try to make
kmalloc(0) illegal
On Aug 18 2007 01:40, Thomas Gleixner wrote:
Do we really ?
If yes, who invented this 1980s reminiscence, where you got valid
pointers for malloc(0) ?
This is completely stupid. You do not go into a bar and order an empty
glass, just because you might eventually become thirsty later.
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
> If yes, who invented this 1980s reminiscence, where you got valid
> pointers for malloc(0) ?
I believe his first name started with an L and ended with an s ;-)
Seriously the kmalloc(0) pointer allowed us to detect cases in which
people tried to
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
> On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
> > On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > That was merged over my objections. IMHO ksize(NULL) should fail since we
> > > are determining the size of an unallocated
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
> On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > That was merged over my objections. IMHO ksize(NULL) should fail since we
> > are determining the size of an unallocated object.
>
> Agreed, especially as we have real zero-sized
On Sat, 18 Aug 2007, Pekka Enberg wrote:
> Agreed, especially as we have real zero-sized objects returned from
> kmalloc() et al now.
Slab allocators: Fail if ksize is called with a NULL parameter
A NULL pointer means that the object was not allocated. One cannot
determine the size of an
On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> That was merged over my objections. IMHO ksize(NULL) should fail since we
> are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
-
To unsubscribe from
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
>
> > Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
> > return 0).
>
> That was merged over my objections. IMHO ksize(NULL) should fail since we
> are determining the size of an
On Sat, 18 Aug 2007, Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Christoph Lameter wrote:
>
> > On Fri, 17 Aug 2007, Andrew Morton wrote:
> >
> > > are we seeing a pattern here? We could stick the unlikely inside
> > > ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there
>
On Sat, 18 Aug 2007, Satyam Sharma wrote:
> > page = get_object_page(object);
>
> Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
> return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
> Oh
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Andrew Morton wrote:
>
> > are we seeing a pattern here? We could stick the unlikely inside
> > ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
> > be future callsites at which it is likely, who
On Fri, 17 Aug 2007, Andrew Morton wrote:
> On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
> >
> > Considering kfree(NULL) would normally occur only in error paths and
> >
On Fri, 17 Aug 2007, Andrew Morton wrote:
> are we seeing a pattern here? We could stick the unlikely inside
> ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
> be future callsites at which it is likely, who knows?
Thought about that myself but then there would be a
On Fri, 17 Aug 2007, Arjan van de Ven wrote:
>
> On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
> > On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
> > Satyam Sharma <[EMAIL PROTECTED]> wrote:
> >
> > > [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
> > >
> > >
On Aug 17 2007 11:22, Andrew Morton wrote:
>Which is getting pretty idiotic:
>
>akpm:/usr/src/25> grep ZERO_OR_NULL_PTR */*.c
>mm/slab.c: BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
>mm/slab.c: if (unlikely(ZERO_OR_NULL_PTR(cachep)))
>mm/slab.c: if
On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
> On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
> >
> > Considering kfree(NULL) would normally occur only in error paths and
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
>
> Considering kfree(NULL) would normally occur only in error paths and
> kfree(ZERO_SIZE_PTR) is uncommon as well, so let's use unlikely()
On Fri, 17 Aug 2007, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL)
On Aug 17 2007 11:22, Andrew Morton wrote:
Which is getting pretty idiotic:
akpm:/usr/src/25 grep ZERO_OR_NULL_PTR */*.c
mm/slab.c: BUG_ON(ZERO_OR_NULL_PTR(cachep-slabp_cache));
mm/slab.c: if (unlikely(ZERO_OR_NULL_PTR(cachep)))
mm/slab.c: if
On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
kfree(ZERO_SIZE_PTR) is uncommon as well, so let's use unlikely() for
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
be future callsites at which it is likely, who knows?
Thought about that myself but then there would be a
On Fri, 17 Aug 2007, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
kfree(ZERO_SIZE_PTR)
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
be future callsites at which it is likely, who knows?
On Sat, 18 Aug 2007, Satyam Sharma wrote:
page = get_object_page(object);
Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Oh yes,
On Sat, 18 Aug 2007, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there
might
be
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
-
To unsubscribe from this
On Sat, 18 Aug 2007, Pekka Enberg wrote:
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
Slab allocators: Fail if ksize is called with a NULL parameter
A NULL pointer means that the object was not allocated. One cannot
determine the size of an object
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
If yes, who invented this 1980s reminiscence, where you got valid
pointers for malloc(0) ?
I believe his first name started with an L and ended with an s ;-)
Seriously the kmalloc(0) pointer allowed us to detect cases in which
people tried to store
Jan Engelhardt wrote:
> 0 is all-bits-zero.
> NULL is 0. ("It is.", above)
>
> Transitively, this would make NULL all-bits-zero.
> I might have missed something, though, perhaps that the cast to void* makes it
> intransitive.
It does -- a cast from integer to pointer isn't required to be a
On Aug 15, 2007, at 10:06:49, Jan Engelhardt wrote:
On Aug 15 2007 09:58, Kyle Moffett wrote:
Irrespective of whatever the standard says, EVERY platform and
compiler anybody makes nowadays has a NULL pointer value with all
bits clear. Theoretically the standard allows otherwise, but such
On Aug 15 2007 09:58, Kyle Moffett wrote:
>
> Irrespective of whatever the standard says, EVERY platform and
> compiler anybody makes nowadays has a NULL pointer value with all
> bits clear. Theoretically the standard allows otherwise, but such
> a decision would break so much code. Linux
On Aug 15, 2007, at 06:20:27, Jan Engelhardt wrote:
On Aug 15 2007 11:58, Rene Herman wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
He said the null _pointer_ isn't guaranteed to be all-bits zero.
And it isn't. Read the standard or the faq.
On 08/15/2007 12:20 PM, Jan Engelhardt wrote:
On Aug 15 2007 11:58, Rene Herman wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
He said the null _pointer_ isn't guaranteed to be all-bits zero. And it
isn't. Read the standard or the faq.
0 is
On Aug 15 2007 11:58, Rene Herman wrote:
>> > > > > NULL is not 0 though.
>> > > > It is. Its representation isn't guaranteed to be all-bits-zero,
>> > >
>
> He said the null _pointer_ isn't guaranteed to be all-bits zero. And it
> isn't. Read the standard or the faq.
0 is all-bits-zero.
NULL
On 08/15/2007 11:20 AM, Jan Engelhardt wrote:
On Aug 15 2007 10:37, Rene Herman wrote:
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its
On Wed, Aug 15, 2007 at 11:20:33 +0200, Jan Engelhardt wrote:
>
> On Aug 15 2007 10:37, Rene Herman wrote:
> > On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
> >> On Aug 14 2007 16:21, Jason Uhlenkott wrote:
> >
> >> > On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
> >> > > NULL
Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
Hmm. It depends on your interpretation of
On Aug 15 2007 10:37, Rene Herman wrote:
> On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
>> On Aug 14 2007 16:21, Jason Uhlenkott wrote:
>
>> > On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
>> > > NULL is not 0 though.
>> > It is. Its representation isn't guaranteed to be
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Aug 14 2007 16:21, Jason Uhlenkott wrote:
>>On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
>>> NULL is not 0 though.
>>
>>It is. Its representation isn't guaranteed to be all-bits-zero,
>
> C guarantees that.
Linux C does it. But
On Wed, Aug 15, 2007 at 09:28:54 +0200, Jan Engelhardt wrote:
>
> On Aug 14 2007 16:21, Jason Uhlenkott wrote:
> >On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
> >> NULL is not 0 though.
> >
> >It is. Its representation isn't guaranteed to be all-bits-zero,
>
> C guarantees
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
C guarantees what? If
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
>On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
>> NULL is not 0 though.
>
>It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
>but the constant value 0 when used in pointer context is always a
>null
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
but the constant value 0 when used in pointer context is always a
null pointer
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
C guarantees what? If
On Wed, Aug 15, 2007 at 09:28:54 +0200, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
Equality
Jan Engelhardt [EMAIL PROTECTED] writes:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
Linux C does it. But not Standard
On Aug 15 2007 10:37, Rene Herman wrote:
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C
Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
C guarantees that.
Hmm. It depends on your interpretation of
On Wed, Aug 15, 2007 at 11:20:33 +0200, Jan Engelhardt wrote:
On Aug 15 2007 10:37, Rene Herman wrote:
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
On 08/15/2007 11:20 AM, Jan Engelhardt wrote:
On Aug 15 2007 10:37, Rene Herman wrote:
On 08/15/2007 09:28 AM, Jan Engelhardt wrote:
On Aug 14 2007 16:21, Jason Uhlenkott wrote:
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its
On Aug 15 2007 11:58, Rene Herman wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
He said the null _pointer_ isn't guaranteed to be all-bits zero. And it
isn't. Read the standard or the faq.
0 is all-bits-zero.
NULL is 0. (It is.,
On 08/15/2007 12:20 PM, Jan Engelhardt wrote:
On Aug 15 2007 11:58, Rene Herman wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
He said the null _pointer_ isn't guaranteed to be all-bits zero. And it
isn't. Read the standard or the faq.
0 is
On Aug 15, 2007, at 06:20:27, Jan Engelhardt wrote:
On Aug 15 2007 11:58, Rene Herman wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero,
He said the null _pointer_ isn't guaranteed to be all-bits zero.
And it isn't. Read the standard or the faq.
On Aug 15 2007 09:58, Kyle Moffett wrote:
Irrespective of whatever the standard says, EVERY platform and
compiler anybody makes nowadays has a NULL pointer value with all
bits clear. Theoretically the standard allows otherwise, but such
a decision would break so much code. Linux
On Aug 15, 2007, at 10:06:49, Jan Engelhardt wrote:
On Aug 15 2007 09:58, Kyle Moffett wrote:
Irrespective of whatever the standard says, EVERY platform and
compiler anybody makes nowadays has a NULL pointer value with all
bits clear. Theoretically the standard allows otherwise, but such
Jan Engelhardt wrote:
0 is all-bits-zero.
NULL is 0. (It is., above)
Transitively, this would make NULL all-bits-zero.
I might have missed something, though, perhaps that the cast to void* makes it
intransitive.
It does -- a cast from integer to pointer isn't required to be a bitwise
noop.
On Wed, 15 Aug 2007, Satyam Sharma wrote:
> [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Good that actually has a code impact.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 14 Aug 2007, Arjan van de Ven wrote:
>
> On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
> > Hi all,
> >
> > I have a quick question.
> >
> > I'm trying to resurrect a patch from the Linux-tiny patch suite,
> > to do accounting of kmalloc memory allocations. In testing it
> >
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
> NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero, but
the constant value 0 when used in pointer context is always a null
pointer (and in fact the standard requires that NULL be #defined as 0
or
Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this considered OK? Or should I examine
On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
> Hi all,
>
> I have a quick question.
>
> I'm trying to resurrect a patch from the Linux-tiny patch suite,
> to do accounting of kmalloc memory allocations. In testing it
> with Linux 2.6.22, I've found a large number of kfrees of
> NULL
On Tue, 14 Aug 2007, Tim Bird wrote:
> Hi all,
>
> I have a quick question.
>
> I'm trying to resurrect a patch from the Linux-tiny patch suite,
> to do accounting of kmalloc memory allocations. In testing it
> with Linux 2.6.22, I've found a large number of kfrees of
> NULL pointers.
>
>
On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
On Tue, 14 Aug 2007, Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this
Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this considered OK? Or should I examine
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero, but
the constant value 0 when used in pointer context is always a null
pointer (and in fact the standard requires that NULL be #defined as 0
or a
On Tue, 14 Aug 2007, Arjan van de Ven wrote:
On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22,
On Wed, 15 Aug 2007, Satyam Sharma wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Good that actually has a code impact.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
74 matches
Mail list logo
