linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Feng Tang <feng.tang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: 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: Wed, 23 Nov 2022 10:21:03 +0100	[thread overview]
Message-ID: <74d14df1-faa7-dc12-d406-ba038682e134@suse.cz> (raw)
In-Reply-To: <Y3xeYF5NipSbBFSZ@feng-clx>

On 11/22/22 06:30, Feng Tang wrote:
> 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.

You could try mm/slab.h instead, below the slub_def.h includes there.
is_kmalloc_cache(s) shouldn't have random consumers in the kernel anyway.
It's fine if kasan includes it, as it's intertwined with slab a lot anyway.

> 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 :)

Can't agree more :)

>> 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?

The overhead of function call between compilation units (sans LTO) is not
worth it.

> 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
>   */



  parent reply	other threads:[~2022-11-23  9:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 13:50 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
2022-11-22 23:17     ` Andrew Morton
2022-11-23  9:21     ` Vlastimil Babka [this message]
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=74d14df1-faa7-dc12-d406-ba038682e134@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=cl@linux.com \
    --cc=dvyukov@google.com \
    --cc=feng.tang@intel.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=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