Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751840AbaBKSn5 (ORCPT ); Tue, 11 Feb 2014 13:43:57 -0500 Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80]:57138 "EHLO qmta08.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751656AbaBKSni (ORCPT ); Tue, 11 Feb 2014 13:43:38 -0500 Date: Tue, 11 Feb 2014 12:43:35 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@nuc To: Pekka Enberg cc: Paul McKenney , "linux-mm@kvack.org" , LKML , Matt Mackall Subject: Re: Memory allocator semantics In-Reply-To: Message-ID: References: <20140102203320.GA27615@linux.vnet.ibm.com> <52F60699.8010204@iki.fi> <20140209020004.GY4250@linux.vnet.ibm.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 Feb 2014, Pekka Enberg wrote: > So again, there's nothing in (A) that the memory allocator is > concerned about. kmalloc() makes no guarantees whatsoever about the > visibility of "r1" across CPUs. If you're saying that there's an > implicit barrier between kmalloc() and kfree(), that's an unintended > side-effect, not a design decision AFAICT. I am not sure that this side effect necessarily happens. The SLUB fastpath does not disable interrupts and only uses a cmpxchg without lock semantics. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/