Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754117AbdGLTV5 (ORCPT ); Wed, 12 Jul 2017 15:21:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34410 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871AbdGLTV4 (ORCPT ); Wed, 12 Jul 2017 15:21:56 -0400 Date: Wed, 12 Jul 2017 12:21:54 -0700 From: Andrew Morton To: Alexander Potapenko Cc: Christoph Lameter , Dmitriy Vyukov , Kostya Serebryany , LKML , Linux Memory Management List , Pekka Enberg , David Rientjes , Joonsoo Kim Subject: Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication Message-Id: <20170712122154.f6bafdc86ccfd189fefbb0a3@linux-foundation.org> In-Reply-To: References: <20170707083408.40410-1-glider@google.com> <20170707132351.4f10cd778fc5eb58e9cc5513@linux-foundation.org> <20170710133238.2afcda57ea28e020ca03c4f0@linux-foundation.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2377 Lines: 70 On Wed, 12 Jul 2017 16:11:28 +0200 Alexander Potapenko wrote: > >> At creation time the kmem_cache structure is private and no one can run a > >> free operation. > I've double-checked the code path and this turned out to be a false > positive caused by KMSAN not instrumenting the contents of mm/slub.c > (i.e. the initialization of the spinlock remained unnoticed). > Christoph is indeed right that kmem_cache_structure is private, so a > race is not possible here. > I am sorry for the false alarm. > >> > 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. > If the maintainers agree the initialization order needs to be fixed, > we'll need to remove the (irrelevant) KMSAN report from the patch > description. Yup. I did this: From: Alexander Potapenko Subject: slub: tidy up initialization ordering - free_kmem_cache_nodes() frees the cache node before nulling out a reference to it - init_kmem_cache_nodes() publishes the cache node before initializing it Neither of these matter at runtime because the cache nodes cannot be looked up by any other thread. But it's neater and more consistent to reorder these. Link: http://lkml.kernel.org/r/20170707083408.40410-1-glider@google.com Signed-off-by: Alexander Potapenko Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton --- mm/slub.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN mm/slub.c~slub-make-sure-struct-kmem_cache_node-is-initialized-before-publication mm/slub.c --- a/mm/slub.c~slub-make-sure-struct-kmem_cache_node-is-initialized-before-publication +++ a/mm/slub.c @@ -3358,8 +3358,8 @@ static void free_kmem_cache_nodes(struct struct kmem_cache_node *n; for_each_kmem_cache_node(s, node, n) { - kmem_cache_free(kmem_cache_node, n); s->node[node] = NULL; + kmem_cache_free(kmem_cache_node, n); } } @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct return 0; } - s->node[node] = n; init_kmem_cache_node(n); + s->node[node] = n; } return 1; } _