[-next,1/2] mm/slab: add is_kmalloc_cache() helper macro

  commit 6edf2576a6cc ("mm/slub: enable debugging memory wasting of
kmalloc") introduces 'SLAB_KMALLOC' bit specifying whether a
kmem_cache is a kmalloc cache for slab/slub (slob doesn't have
dedicated kmalloc caches).

Add a helper macro for other components like kasan to simplify code.

Signed-off-by: Feng Tang <feng.tang@intel.com>
---
 include/linux/slab.h | 6 ++++++
 1 file changed, 6 insertions(+)
  

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?

If so, that's always best.  For (silly) example, consider the behaviour
of

	x = is_kmalloc_cache(s++);

with and without CONFIG_SLOB.
  

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

On Tue, 22 Nov 2022 13:30:19 +0800 Feng Tang <feng.tang@intel.com> wrote:

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

I'm not sure that's much of an improvement on the macro :(

How about we go with the macro and avoid the
expression-with-side-effects gotcha (and the potential CONFIG_SLOB=n
unused-variable gotcha)?  That would involve evaluating the arg within
the CONFIG_SLOB=y version of the macro.
  

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

On Wed, Nov 23, 2022 at 10:21:03AM +0100, Vlastimil Babka wrote:
> 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.
 
Good suggestion! thanks! This can address Andrew's concern and also
avoid extra cost.    

And yes, besides sanity code like kasan/kfence, rare code will care
whether other kmem_cache is a kmalloc cache or not. And kasan code
already includes "../slab.h".

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

Yes. Will send out the v2 patches. 

Thanks,
Feng