Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752655AbdGGXSg (ORCPT ); Fri, 7 Jul 2017 19:18:36 -0400 Received: from resqmta-ch2-12v.sys.comcast.net ([69.252.207.44]:49842 "EHLO resqmta-ch2-12v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751816AbdGGXSe (ORCPT ); Fri, 7 Jul 2017 19:18:34 -0400 Date: Fri, 7 Jul 2017 18:18:31 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@east.gentwo.org To: Andrew Morton cc: Alexander Potapenko , dvyukov@google.com, kcc@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg , David Rientjes , Joonsoo Kim Subject: Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication In-Reply-To: <20170707132351.4f10cd778fc5eb58e9cc5513@linux-foundation.org> Message-ID: References: <20170707083408.40410-1-glider@google.com> <20170707132351.4f10cd778fc5eb58e9cc5513@linux-foundation.org> Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfIkkxDGONnutZVILC13BwQBVPsjINsIcxpl6++XTcxz6VtW6Z1S4wFsdDzysCw2NGXD9WF0STpaRsnqSPmjjviW2aANnG2eaAeRNLBAiJ+5datqJcFaI +vWYcUGfF8RGEBL81Ga+9PBrhJmUnGTdo69EbjIw7r6rQ0kKFYQFnsKNgABTE6Ye4OJDb1vckysV7nzldrZSIteIj4Dl1+JTl7He/jcds9JHBRlFkKT/xdr1 QBu3sOZXMPTlacXj0Fy8+8U24y5ltns9uOF5s8yRNP7TKo000d84jmUz8xoapY1o2p8sZZT77ntjRZzPjh/sn8PX/iELL1NG1rZ8wffpiU0qjOkkvZYWS8oY 79ckwS7lG08rNl18hvHbesSS/Fy4pIR9DcNPrQ2CXXovdm6gj8oGQcjtHlvm+5R96KaFFkQp Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 833 Lines: 31 On Fri, 7 Jul 2017, Andrew Morton wrote: > On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko 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. > 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?