From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by kanga.kvack.org (Postfix) with ESMTP id E197A6B0038 for ; Wed, 9 Sep 2015 20:21:35 -0400 (EDT) Received: by ioii196 with SMTP id i196so42164964ioi.3 for ; Wed, 09 Sep 2015 17:21:35 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net. [2001:558:fe21:29:69:252:207:38]) by mx.google.com with ESMTPS id h142si8095937ioh.159.2015.09.09.17.21.35 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 17:21:35 -0700 (PDT) Date: Wed, 9 Sep 2015 19:21:34 -0500 (CDT) From: Christoph Lameter Subject: Re: Store Buffers (was Re: Is it OK to pass non-acquired objects to kfree?) In-Reply-To: <20150910000847.GV4029@linux.vnet.ibm.com> Message-ID: References: <20150909184415.GJ4029@linux.vnet.ibm.com> <20150909203642.GO4029@linux.vnet.ibm.com> <20150910000847.GV4029@linux.vnet.ibm.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: "Paul E. McKenney" Cc: Dmitry Vyukov , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , "linux-mm@kvack.org" , Andrey Konovalov , Alexander Potapenko On Wed, 9 Sep 2015, Paul E. McKenney wrote: > The CPU is indeed constrained in this way, but the compiler is not. > In particular, the CPU must do exact alias analysis, while the compiler > is permitted to do approximate alias analysis in some cases. However, > in gcc builds of the Linux kernel, I believe that the -fno-strict-aliasing > gcc command-line argument forces exact alias analysis. > > Dmitry, anything that I am missing? > > > The transfer to another processor is guarded by locks and I think that > > those are enough to ensure that the cachelines become visible in a > > controlled fashion. > > For the kfree()-to-kmalloc() path, I do believe that you are correct. > Dmitry's question was leading up to the kfree(). The kmalloc-to-kfree path has similar bounds that ensure correctness. First of all it is the availability of the pointer and the transfer of the contents of the pointer to a remove processor. Strictly speaking the processor would violate the rule that there cannnot be a memory access to the object after kfree is called if the compiler would move a store into kfree(). But then again kfree() contains a barrier() which would block the compiler from moving anything into the free path. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org