[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c77e82629f04f0183853884abbeddd871d8f5ab7.camel@oracle.com>
Date: Fri, 08 Nov 2019 17:44:10 +0100
From: Knut Omang <knut.omang@...cle.com>
To: Christopher Lameter <cl@...ux.com>,
Michal Hocko <mhocko@...nel.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
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 Fri, 2019-11-08 at 15:37 +0000, Christopher Lameter wrote:
> On Thu, 7 Nov 2019, Michal Hocko wrote:
>
> > On Thu 07-11-19 13:26:09, Knut Omang wrote:
> > > 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
>
> That patch only affected the memcg_cache_params structure and not
> kmem_cache.
>
> And I do not see any references to the memcg_cache_param?
Good point, I should have made explicit reference to it.
It gets inlined into kmem_cache with CONFIG_SLUB if CONFIG_MEMCG is set
(include/linux/slub_def.h, line 112)
> The fields that all allocators need to expose are listed in
> the struct kmme_cache definition in linux/mm/slab.h.
So I take that kmem_cache::name was still intended to be public,
just that that broke due to the inlining of struct memcg_cache_param
in slub_def.h?
Knut
Powered by blists - more mailing lists