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@xxxxxxxxx> 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
