Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752905AbdGLT5z (ORCPT ); Wed, 12 Jul 2017 15:57:55 -0400 Received: from resqmta-ch2-04v.sys.comcast.net ([69.252.207.36]:59966 "EHLO resqmta-ch2-04v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772AbdGLT5y (ORCPT ); Wed, 12 Jul 2017 15:57:54 -0400 Date: Wed, 12 Jul 2017 14:57:47 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Andrew Morton cc: Alexander Potapenko , 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 In-Reply-To: <20170712122154.f6bafdc86ccfd189fefbb0a3@linux-foundation.org> Message-ID: References: <20170707083408.40410-1-glider@google.com> <20170707132351.4f10cd778fc5eb58e9cc5513@linux-foundation.org> <20170710133238.2afcda57ea28e020ca03c4f0@linux-foundation.org> <20170712122154.f6bafdc86ccfd189fefbb0a3@linux-foundation.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfBqcRVxpW+e61QWMgDVoXK3GIVHEUs5deEycIsP97gKkmkwI0pPvFHcOK/lN71K0MxKdkHJEbX0EtyEsvpYJGqrtV6+K2rPX1QczqeIbN74yEJKHL2tP DouHxV0H7NK2XU24XqgAruzmb87geOsn4YZIgZ9EbIVPrGTrmDsMztiqJKAK9H51PZKztWwkjznLUyLbBALPkaYve5n7RYT6PZ3ZjvC+uj7sNWtp8sWOhGf0 osoPinS/gkInlAzf1knk4AWQQrD4ldueuq5FsBXF8TffcaQYEmBEbAOGFMnrUe0KZasFKOYlE0ngEdHSpsn6byrFb5pHyc65iA5EG7TWu6H1AXl+uHGe9kfR j2VB6AMAJZ7gvQDg7lmcQA4Ye389ImFpT+lmB6/RVy2ZFBjK+OwsX2MgG2AIjak7Om78Lw9j Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 502 Lines: 16 On Wed, 12 Jul 2017, Andrew Morton wrote: > - 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. The compiler or processor may reorder them at will anyways. But if its tidier.... Acked-by: Christoph Lameter