From: Feng Tang <feng.tang@intel.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
John Thomson <lists@johnthomson.fastmail.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Dmitry Vyukov" <dvyukov@google.com>,
Jonathan Corbet <corbet@lwn.net>,
"Andrey Konovalov" <andreyknvl@gmail.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
Robin Murphy <robin.murphy@arm.com>,
John Garry <john.garry@huawei.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc
Date: Fri, 4 Nov 2022 11:52:07 +0800 [thread overview]
Message-ID: <Y2SMZ0//dReS/NMV@feng-clx> (raw)
In-Reply-To: <55ace2db-80b6-04db-e8b5-03bd3b5061cf@suse.cz>
On Thu, Nov 03, 2022 at 06:35:53PM +0100, Vlastimil Babka wrote:
[...]
> >> But FYI I'm suggesting to drop CONFIG_TRACING=n variant:
> >>
> >> https://lore.kernel.org/linux-mm/20221101222520.never.109-kees@kernel.org/T/#m20ecf14390e406247bde0ea9cce368f469c539ed
> >>
> >> Any thoughts?
> >
> > I'll get to it, also I think we were pondering that within your series too,
> > but I wanted to postpone in case somebody objects to the extra function call
> > it creates.
> > But that would be for 6.2 anyway while I'll collect the fix here for 6.1.
>
> On second thought, the fix is making the inlined kmalloc_trace() expand to a
> call that had 2 parameters and now it has 5, which seems to me like a worse
> thing (code bloat) than the function call. With the other reasons to ditch
> the CONFIG_TRACING=n variant I'm inclined to just do it right now.
That's great! It will save much trouble, and reduce code complexity.
Btw, the patch below also has some compiling issue for some kconfig
(thanks to 0Day's kbuild bot).
Thanks,
Feng
> >>>
> >>> How about the following fix?
> >>>
> >>> Thanks,
> >>> Feng
> >>>
> >>> ---
> >>> From 9f9fa9da8946fd44625f873c0f51167357075be1 Mon Sep 17 00:00:00 2001
> >>> From: Feng Tang <feng.tang@intel.com>
> >>> Date: Thu, 3 Nov 2022 21:32:10 +0800
> >>> Subject: [PATCH] mm/slub: Add missing orig_size parameter for wastage debug
> >>>
> >>> commit 6edf2576a6cc ("mm/slub: enable debugging memory wasting of
> >>> kmalloc") was introduced for debugging kmalloc memory wastage,
> >>> and it missed to pass the original request size for kmalloc_trace()
> >>> and kmalloc_node_trace() in CONFIG_TRACING=n path.
> >>>
> >>> Fix it by using __kmem_cache_alloc_node() with correct original
> >>> request size.
> >>>
> >>> Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc")
> >>> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> >>> Signed-off-by: Feng Tang <feng.tang@intel.com>
> >>> ---
> >>> include/linux/slab.h | 9 +++++++--
> >>> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/include/linux/slab.h b/include/linux/slab.h
> >>> index 90877fcde70b..9691afa569e1 100644
> >>> --- a/include/linux/slab.h
> >>> +++ b/include/linux/slab.h
> >>> @@ -469,6 +469,9 @@ void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_kmalloc_alignm
> >>> __alloc_size(1);
> >>> void *kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node) __assume_slab_alignment
> >>> __malloc;
> >>> +void *__kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node,
> >>> + size_t orig_size, unsigned long caller) __assume_slab_alignment
> >>> + __malloc;
> >>>
> >>> #ifdef CONFIG_TRACING
> >>> void *kmalloc_trace(struct kmem_cache *s, gfp_t flags, size_t size)
> >>> @@ -482,7 +485,8 @@ void *kmalloc_node_trace(struct kmem_cache *s, gfp_t gfpflags,
> >>> static __always_inline __alloc_size(3)
> >>> void *kmalloc_trace(struct kmem_cache *s, gfp_t flags, size_t size)
> >>> {
> >>> - void *ret = kmem_cache_alloc(s, flags);
> >>> + void *ret = __kmem_cache_alloc_node(s, flags, NUMA_NO_NODE,
> >>> + size, _RET_IP_);
> >>>
> >>> ret = kasan_kmalloc(s, ret, size, flags);
> >>> return ret;
> >>> @@ -492,7 +496,8 @@ static __always_inline __alloc_size(4)
> >>> void *kmalloc_node_trace(struct kmem_cache *s, gfp_t gfpflags,
> >>> int node, size_t size)
> >>> {
> >>> - void *ret = kmem_cache_alloc_node(s, gfpflags, node);
> >>> + void *ret = __kmem_cache_alloc_node(s, gfpflags, node,
> >>> + size, _RET_IP_);
> >>>
> >>> ret = kasan_kmalloc(s, ret, size, gfpflags);
> >>> return ret;
> >>> --
> >>> 2.34.1
> >>>
> >>>
> >>>
> >>
> >
>
>
prev parent reply other threads:[~2022-11-04 3:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220913065423.520159-1-feng.tang@intel.com>
[not found] ` <20220913065423.520159-2-feng.tang@intel.com>
[not found] ` <becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com>
[not found] ` <af2ba83d-c3f4-c6fb-794e-c2c7c0892c44@suse.cz>
[not found] ` <Y180l6zUnNjdCoaE@feng-clx>
[not found] ` <c4285caf-277c-45fd-8fc7-8a1d61685ce8@app.fastmail.com>
[not found] ` <Y1+0sbQ3R4DB46NX@feng-clx>
[not found] ` <9b71ae3e-7f53-4c9e-90c4-79d3d649f94c@app.fastmail.com>
2022-11-01 7:57 ` [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-11-01 9:20 ` John Thomson
2022-11-01 9:31 ` Hyeonggon Yoo
2022-11-01 10:33 ` John Thomson
2022-11-01 10:42 ` Hyeonggon Yoo
2022-11-01 13:55 ` Feng Tang
2022-11-01 19:39 ` John Thomson
2022-11-02 6:08 ` Feng Tang
2022-11-02 7:16 ` Hyeonggon Yoo
2022-11-03 7:18 ` Feng Tang
2022-11-03 7:45 ` John Thomson
2022-11-03 8:16 ` Feng Tang
2022-11-02 8:22 ` Vlastimil Babka
2022-11-03 5:54 ` Feng Tang
2022-11-03 8:33 ` Vlastimil Babka
2022-11-03 14:16 ` Feng Tang
2022-11-03 14:36 ` Hyeonggon Yoo
2022-11-03 16:57 ` Vlastimil Babka
2022-11-03 17:35 ` Vlastimil Babka
2022-11-04 3:52 ` Feng Tang [this message]
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=Y2SMZ0//dReS/NMV@feng-clx \
--to=feng.tang@intel.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dvyukov@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=john.garry@huawei.com \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lists@johnthomson.fastmail.com.au \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=robin.murphy@arm.com \
--cc=roman.gushchin@linux.dev \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).