From: Feng Tang <feng.tang@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
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>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
<linux-mm@kvack.org>, <kasan-dev@googlegroups.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro
Date: Tue, 22 Nov 2022 13:30:19 +0800 [thread overview]
Message-ID: <Y3xeYF5NipSbBFSZ@feng-clx> (raw)
In-Reply-To: <20221121121938.1f202880ffe6bb18160ef785@linux-foundation.org>
On Mon, Nov 21, 2022 at 12:19:38PM -0800, Andrew Morton wrote:
> On Mon, 21 Nov 2022 21:50:23 +0800 Feng Tang <feng.tang@intel.com> wrote:
>
> > +#ifndef CONFIG_SLOB
> > +#define is_kmalloc_cache(s) ((s)->flags & SLAB_KMALLOC)
> > +#else
> > +#define is_kmalloc_cache(s) (false)
> > +#endif
>
> Could be implemented as a static inline C function, yes?
Right, I also did try inline function first, and met compilation error:
"
./include/linux/slab.h: In function ‘is_kmalloc_cache’:
./include/linux/slab.h:159:18: error: invalid use of undefined type ‘struct kmem_cache’
159 | return (s->flags & SLAB_KMALLOC);
| ^~
"
The reason is 'struct kmem_cache' definition for slab/slub/slob sit
separately in slab_def.h, slub_def.h and mm/slab.h, and they are not
included in this 'include/linux/slab.h'. So I chose the macro way.
Btw, I've worked on some patches related with sl[auo]b recently, and
really felt the pain when dealing with 3 allocators, on both reading
code and writing patches. And I really like the idea of fading away
SLOB as the first step :)
> If so, that's always best. For (silly) example, consider the behaviour
> of
>
> x = is_kmalloc_cache(s++);
>
> with and without CONFIG_SLOB.
Another solution I can think of is putting the implementation into
slab_common.c, like the below?
Thanks,
Feng
---
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 067f0e80be9e..e4fcdbfb3477 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -149,6 +149,17 @@
struct list_lru;
struct mem_cgroup;
+
+#ifndef CONFIG_SLOB
+extern bool is_kmalloc_cache(struct kmem_cache *s);
+#else
+static inline bool is_kmalloc_cache(struct kmem_cache *s)
+{
+ return false;
+}
+#endif
+
/*
* struct kmem_cache related prototypes
*/
diff --git a/mm/slab_common.c b/mm/slab_common.c
index a5480d67f391..860e804b7c0a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -77,6 +77,13 @@ __setup_param("slub_merge", slub_merge, setup_slab_merge, 0);
__setup("slab_nomerge", setup_slab_nomerge);
__setup("slab_merge", setup_slab_merge);
+#ifndef CONFIG_SLOB
+bool is_kmalloc_cache(struct kmem_cache *s)
+{
+ return (s->flags & SLAB_KMALLOC);
+}
+#endif
+
/*
* Determine the size of a slab object
*/
next prev parent reply other threads:[~2022-11-22 5:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 13:50 [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro Feng Tang
2022-11-21 13:50 ` [PATCH -next 2/2] mm/kasan: simplify is_kmalloc check Feng Tang
2022-11-21 14:13 ` Feng Tang
2022-11-21 15:15 ` Andrey Konovalov
2022-11-22 6:53 ` Feng Tang
2022-11-22 9:57 ` Andrey Konovalov
2022-11-21 20:19 ` [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro Andrew Morton
2022-11-22 5:30 ` Feng Tang [this message]
2022-11-22 23:17 ` Andrew Morton
2022-11-23 9:21 ` Vlastimil Babka
2022-11-23 12:17 ` Feng Tang
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=Y3xeYF5NipSbBFSZ@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=dvyukov@google.com \
--cc=glider@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=ryabinin.a.a@gmail.com \
--cc=vbabka@suse.cz \
--cc=vincenzo.frascino@arm.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).