[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170710133238.2afcda57ea28e020ca03c4f0@linux-foundation.org>
Date: Mon, 10 Jul 2017 13:32:38 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Christoph Lameter <cl@...ux.com>
Cc: Alexander Potapenko <glider@...gle.com>, dvyukov@...gle.com,
kcc@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH] slub: make sure struct kmem_cache_node is initialized
before publication
On Fri, 7 Jul 2017 18:18:31 -0500 (CDT) Christoph Lameter <cl@...ux.com> wrote:
> On Fri, 7 Jul 2017, Andrew Morton wrote:
>
> > On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko <glider@...gle.com> wrote:
> >
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache *s)
> > > return 0;
> > > }
> > >
> > > - s->node[node] = n;
> > > init_kmem_cache_node(n);
> > > + s->node[node] = n;
> > > }
> > > return 1;
> > > }
> >
> > If this matters then I have bad feelings about free_kmem_cache_nodes():
>
> At creation time the kmem_cache structure is private and no one can run a
> free operation.
>
> > Inviting a use-after-free? I guess not, as there should be no way
> > to look up these items at this stage.
>
> Right.
Still. It looks bad, and other sites do these things in the other order.
> > Could the slab maintainers please take a look at these and also have a
> > think about Alexander's READ_ONCE/WRITE_ONCE question?
>
> Was I cced on these?
It's all on linux-mm.
Powered by blists - more mailing lists