lkml.org 
[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] slab, kmemleak, minor, stop calling kmemleak_erase() unconditionally
Catalin Marinas wrote:
> "J. R. Okajima" <hooanon05@yahoo.co.jp> wrote:
>> When the gotten object is NULL (probably due to ENOMEM),
>> kmemleak_erase() is unnecessary here, It just sets NULL to where already
>> is NULL.
>> Add a condition.
>>
>> Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
>> ---
>> mm/slab.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index 7dfa481..4e61449 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -3109,7 +3109,8 @@ static inline void *____cache_alloc(struct kmem_cache *cachep, gfp_t flags)
>> * per-CPU caches is leaked, we need to make sure kmemleak doesn't
>> * treat the array pointers as a reference to the object.
>> */
>> - kmemleak_erase(&ac->entry[ac->avail]);
>> + if (objp)
>> + kmemleak_erase(&ac->entry[ac->avail]);
>> return objp;
>> }
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>

Applied, thanks!


\
 
 \ /
  Last update: 2009-12-06 09:35    [W:0.046 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site