[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0100016388bb8ade-de95df0e-6154-4ddc-98bb-ee33811cca85-000000@email.amazonses.com>
Date: Tue, 22 May 2018 16:43:02 +0000
From: Christopher Lameter <cl@...ux.com>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Shakeel Butt <shakeelb@...gle.com>,
Michal Hocko <mhocko@...nel.org>,
Greg Thelen <gthelen@...gle.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Johannes Weiner <hannes@...xchg.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Tejun Heo <tj@...nel.org>, Linux MM <linux-mm@...ck.org>,
cgroups@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: fix race between kmem_cache destroy, create and
deactivate
On Mon, 21 May 2018, Andrew Morton wrote:
> The patch seems depressingly complex.
>
> And a bit underdocumented...
Maybe separate out the bits that rename refcount to alias_count?
> > + refcount_t refcount;
> > + int alias_count;
>
> The semantic meaning of these two? What locking protects alias_count?
slab_mutex
>
> > int object_size;
> > int align;
> >
> > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > index 3773e26c08c1..532d4b6f83ed 100644
> > --- a/include/linux/slub_def.h
> > +++ b/include/linux/slub_def.h
> > @@ -97,7 +97,8 @@ struct kmem_cache {
> > struct kmem_cache_order_objects max;
> > struct kmem_cache_order_objects min;
> > gfp_t allocflags; /* gfp flags to use on each alloc */
> > - int refcount; /* Refcount for slab cache destroy */
> > + refcount_t refcount; /* Refcount for slab cache destroy */
> > + int alias_count; /* Number of root kmem caches merged */
>
> "merged" what with what in what manner?
That is a basic SLUB feature.
Powered by blists - more mailing lists