linux-kernel - Re: [PATCH -next 1/2] mm/slab: add is_kmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y34PQan6HOucgj4M@feng-clx>
Date:   Wed, 23 Nov 2022 20:17:05 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>
CC:     Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        "Alexander Potapenko" <glider@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        <linux-mm@...ck.org>, <kasan-dev@...glegroups.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro

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