| Message ID | 20221121135024.1655240-1-feng.tang@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [-next,1/2] mm/slab: add is_kmalloc_cache() helper macro | expand |
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
diff --git a/include/linux/slab.h b/include/linux/slab.h index 1c670c16c737..ee6499088ad3 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -758,6 +758,12 @@ extern void kvfree_sensitive(const void *addr, size_t len); unsigned int kmem_cache_size(struct kmem_cache *s); +#ifndef CONFIG_SLOB +#define is_kmalloc_cache(s) ((s)->flags & SLAB_KMALLOC) +#else +#define is_kmalloc_cache(s) (false) +#endif + /** * kmalloc_size_roundup - Report allocation bucket size for the given size *
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(+)