linux-kernel - Re: [PATCH] mm: provide interface for retrieving kmem

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <27006f47b0b85fb99acee2a638207268aef8d010.camel@oracle.com>
Date:   Thu, 07 Nov 2019 13:26:09 +0100
From:   Knut Omang <knut.omang@...cle.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: provide interface for retrieving kmem_cache name

On Thu, 2019-11-07 at 12:58 +0100, Michal Hocko wrote:
> On Thu 07-11-19 12:54:04, Knut Omang wrote:
> > With the restructuring done in commit 9adeaa226988
> > ("mm, slab: move memcg_cache_params structure to mm/slab.h")
> > 
> > it is no longer possible for code external to mm to access
> > the name of a kmem_cache as struct kmem_cache has effectively become
> > opaque. Having access to the cache name is helpful to kernel testing
> > infrastructure.
> > 
> > Expose a new function kmem_cache_name to mitigate that.
> 
> Who is going to use that symbol? It is preferred that a user is added in
> the same patch as the newly added symbol.

Yes, I am aware that that's the normal practice, 
we're currently using cache->name directly in the kernel 
unit test framework KTF (https://github.com/oracle/ktf/)
which we are working (https://lkml.org/lkml/2019/8/13/111) to get 
into the kernel in one form or another.

To me this seems like a natural part of an API for the kmem_cache
data structure now that it has in effect become opaque, so it seemed 
appropriate to get it in close in time to the patch that no longer 
makes this possible, instead of someone else hitting this down the road.

Thanks,
Knut

> > Signed-off-by: Knut Omang <knut.omang@...cle.com>
> > ---
> >  include/linux/slab.h | 1 +
> >  mm/slab_common.c     | 9 +++++++++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index 4d2a2fa55ed5..3298c9db6e46 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -702,6 +702,7 @@ static inline void *kzalloc_node(size_t size, gfp_t flags, int node)
> >  }
> >  
> >  unsigned int kmem_cache_size(struct kmem_cache *s);
> > +const char *kmem_cache_name(struct kmem_cache *s);
> >  void __init kmem_cache_init_late(void);
> >  
> >  #if defined(CONFIG_SMP) && defined(CONFIG_SLAB)
> > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > index f9fb27b4c843..269a99dc8214 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -82,6 +82,15 @@ unsigned int kmem_cache_size(struct kmem_cache *s)
> >  }
> >  EXPORT_SYMBOL(kmem_cache_size);
> >  
> > +/*
> > + * Get the name of a slab object
> > + */
> > +const char *kmem_cache_name(struct kmem_cache *s)
> > +{
> > +	return s->name;
> > +}
> > +EXPORT_SYMBOL(kmem_cache_name);
> > +
> >  #ifdef CONFIG_DEBUG_VM
> >  static int kmem_cache_sanity_check(const char *name, unsigned int size)
> >  {
> > -- 
> > 2.20.1