From: Xiaotian Feng <dfeng@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Matt Mackall <mpm@selenic.com>,
Vegard Nossum <vegard.nossum@gmail.com>,
Dmitry Monakhov <dmonakhov@openvz.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH] slab: fix caller tracking on !CONFIG_DEBUG_SLAB && CONFIG_TRACING
Date: Fri, 09 Apr 2010 14:28:59 +0800 [thread overview]
Message-ID: <4BBEC92B.9060407@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1004081209380.21040@chino.kir.corp.google.com>
On 04/09/2010 03:12 AM, David Rientjes wrote:
> On Thu, 8 Apr 2010, Xiaotian Feng wrote:
>
>> diff --git a/include/linux/slab.h b/include/linux/slab.h
>> index 4884462..1a0625c 100644
>> --- a/include/linux/slab.h
>> +++ b/include/linux/slab.h
>> @@ -267,7 +267,7 @@ static inline void *kmem_cache_alloc_node(struct kmem_cache *cachep,
>> * allocator where we care about the real place the memory allocation
>> * request comes from.
>> */
>> -#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB)
>> +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || defined(CONFIG_TRACING)
>> extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long);
>> #define kmalloc_track_caller(size, flags) \
>> __kmalloc_track_caller(size, flags, _RET_IP_)
>> @@ -285,7 +285,7 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long);
>> * standard allocator where we care about the real place the memory
>> * allocation request comes from.
>> */
>> -#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB)
>> +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || defined(CONFIG_TRACING)
>> extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, unsigned long);
>> #define kmalloc_node_track_caller(size, flags, node) \
>> __kmalloc_node_track_caller(size, flags, node, \
>
> This doesn't work if the underlying slab allocator doesn't define
> __kmalloc_node_track_caller() regardless of whether CONFIG_TRACING is
> enabled or not. SLOB, for example, never defines it, and that's why the
> conditional exists in the way it currently does.
>
Sorry, I didn't realized this, can we use (defined(CONFIG_TRACING) &&
defined(CONFIG_SLAB)) ?
> This is your patch with CONFIG_EMBEDDED&& CONFIG_SLOB:
>
> mm/built-in.o: In function `__krealloc':
> (.text+0x1283c): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kmemdup':
> (.text+0x128b4): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kstrndup':
> (.text+0x128fc): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kstrdup':
> (.text+0x12943): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `memdup_user':
> (.text+0x129f7): undefined reference to `__kmalloc_track_caller'
> drivers/built-in.o:(.text+0xc48a4): more undefined references to `__kmalloc_track_caller' follow
> net/built-in.o: In function `__alloc_skb':
> (.text+0x8dc6): undefined reference to `__kmalloc_node_track_caller'
>
WARNING: multiple messages have this Message-ID (diff)
From: Xiaotian Feng <dfeng@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Matt Mackall <mpm@selenic.com>,
Vegard Nossum <vegard.nossum@gmail.com>,
Dmitry Monakhov <dmonakhov@openvz.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH] slab: fix caller tracking on !CONFIG_DEBUG_SLAB && CONFIG_TRACING
Date: Fri, 09 Apr 2010 14:28:59 +0800 [thread overview]
Message-ID: <4BBEC92B.9060407@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1004081209380.21040@chino.kir.corp.google.com>
On 04/09/2010 03:12 AM, David Rientjes wrote:
> On Thu, 8 Apr 2010, Xiaotian Feng wrote:
>
>> diff --git a/include/linux/slab.h b/include/linux/slab.h
>> index 4884462..1a0625c 100644
>> --- a/include/linux/slab.h
>> +++ b/include/linux/slab.h
>> @@ -267,7 +267,7 @@ static inline void *kmem_cache_alloc_node(struct kmem_cache *cachep,
>> * allocator where we care about the real place the memory allocation
>> * request comes from.
>> */
>> -#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB)
>> +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || defined(CONFIG_TRACING)
>> extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long);
>> #define kmalloc_track_caller(size, flags) \
>> __kmalloc_track_caller(size, flags, _RET_IP_)
>> @@ -285,7 +285,7 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long);
>> * standard allocator where we care about the real place the memory
>> * allocation request comes from.
>> */
>> -#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB)
>> +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB) || defined(CONFIG_TRACING)
>> extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, unsigned long);
>> #define kmalloc_node_track_caller(size, flags, node) \
>> __kmalloc_node_track_caller(size, flags, node, \
>
> This doesn't work if the underlying slab allocator doesn't define
> __kmalloc_node_track_caller() regardless of whether CONFIG_TRACING is
> enabled or not. SLOB, for example, never defines it, and that's why the
> conditional exists in the way it currently does.
>
Sorry, I didn't realized this, can we use (defined(CONFIG_TRACING) &&
defined(CONFIG_SLAB)) ?
> This is your patch with CONFIG_EMBEDDED&& CONFIG_SLOB:
>
> mm/built-in.o: In function `__krealloc':
> (.text+0x1283c): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kmemdup':
> (.text+0x128b4): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kstrndup':
> (.text+0x128fc): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `kstrdup':
> (.text+0x12943): undefined reference to `__kmalloc_track_caller'
> mm/built-in.o: In function `memdup_user':
> (.text+0x129f7): undefined reference to `__kmalloc_track_caller'
> drivers/built-in.o:(.text+0xc48a4): more undefined references to `__kmalloc_track_caller' follow
> net/built-in.o: In function `__alloc_skb':
> (.text+0x8dc6): undefined reference to `__kmalloc_node_track_caller'
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-04-09 6:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 10:11 [PATCH] slab: fix caller tracking on !CONFIG_DEBUG_SLAB && CONFIG_TRACING Xiaotian Feng
2010-04-08 10:11 ` Xiaotian Feng
2010-04-08 19:12 ` David Rientjes
2010-04-08 19:12 ` David Rientjes
2010-04-09 6:28 ` Xiaotian Feng [this message]
2010-04-09 6:28 ` Xiaotian Feng
2010-04-09 16:49 ` David Rientjes
2010-04-09 16:49 ` David Rientjes
2010-06-30 9:57 ` [PATCH V2] " Xiaotian Feng
2010-06-30 9:57 ` Xiaotian Feng
2010-06-30 20:07 ` David Rientjes
2010-06-30 20:07 ` David Rientjes
2010-07-04 16:50 ` Pekka Enberg
2010-07-04 16:50 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBEC92B.9060407@redhat.com \
--to=dfeng@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux-foundation.org \
--cc=dmonakhov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=rientjes@google.com \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.