From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FD513603E0 for ; Thu, 26 Feb 2026 18:06:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772129217; cv=none; b=rYdhO79COeMFsPgwNA2rDb0fHiPrQ6gUHnCZZhykd+rNOEQdu1v57q70ibSM4Ta2bEWMcGjW/NeDOBRDX3d1jkyI8KqKDwpvb1QPaiptpQztzmhLN8dywZSWCUpGvY8wurYFO7Kxo4E6yw2RFR6puw38BbGvT32n4BFPKWLSGGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772129217; c=relaxed/simple; bh=M3CGrm0VhU4itt4g6xjpQh7V8E2y4Aph7J+dstE5F1w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NX8BOw+S0E7/rssRG9JjY3HqdxxPKUtL9XgyRwNQYMQSJViA25T2h/KUSa0WZoJc2foiHt9t9GfF9WNTJDY8uRIszKfmjcU3DO80HXyeUX8yvxOu94GzPAj7IpBNh0qKU5d7ZBboc5hj3xQxbCN/tbl3tEizDhxr+ID2/hKA/Lw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=u2+Wf/1t; arc=none smtp.client-ip=209.85.219.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="u2+Wf/1t" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8972a14e27bso14282566d6.2 for ; Thu, 26 Feb 2026 10:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1772129215; x=1772734015; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4UbRn1/Zoh4IIbiAkpXZr+7zJlNAh6IGPdvB7q6Yi9o=; b=u2+Wf/1thBsV6ilfGPrTtsH8g3TSSLDPwTN38qpsP0TvElVf6ZbvGiwL0xGfrR3JeA ji7hwhN4EVjYns/Nfsgmq3yQH+KVghejaYon7eAlW4PBh+g4KWyLn13hIfaEOKXyn0w1 hpEdDUZZ56Of97pgr376rl5Q2VGFOT6QdVOfNOQa1id1+jMMNID7EUcfLniFJZlb+UzA HrgZdGB8e4m5tmB60YilCkhwvEEtPY9j6R7Ip5pqvI4BilXoebTbk7ZwHUmsLvO+G9AZ whOn4S+vlJX8y7fCmI0FU6r/rzX1Mp64g0p3dY/kkTdfOZ4gF6X90t82PfELxpQbdiLz plUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772129215; x=1772734015; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4UbRn1/Zoh4IIbiAkpXZr+7zJlNAh6IGPdvB7q6Yi9o=; b=WrAV2S8YmVZhBt5nBs5TopalbNq2SgHYiUbToeHXEfkYoozU/naqbj9p76xZFjzSNq AJBbEs9EElL7GekzpL0SzefufRI6dYa38EavhA5IR/QWX66xzJYSPBQd/1tpxIGzDAFW ix3Q68876LBImUWmceEIYzkrCXJt6ISH7r5DhtznRh+60iJX1FyjA93p9NLyfp1GQ/sT 6fcFS9s7oRJpoG6owc8p0o7+6qEZNl2NdmOvSjc5/DBitAKtEfKAZZ2J8gIkl9/Egb/+ 1gXsarR+9+BO2ILzaFwZT6UOOEWuCdiBKFYrVqIY1xTkJkhrjuq9ZcnZjZEhbe2xHASx bEVg== X-Forwarded-Encrypted: i=1; AJvYcCUK1pCQtau0Q+XH9aews4Kg6jybHT8ql8ysdobTNsrgfuQ9pgdVjBKI53kuhAW2W+rQZFXIUmVrMNvSbHE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0KJbZupjdjR/o0qiquWJ8cxnNXOMTVjPxvjW4I+tURhtz9vVZ DctyTpWigzLZBn1XqHuFniBnCHlb8p9zY1KBevko2ch1PI60/jcsNdAFz7UiSkr37Q== X-Gm-Gg: ATEYQzxqgZDdr61WBGNz3f+afUAFAeV5p9GJjNa4gueAa/gnMB2Vnou9vSnWog+V+7o yoNxUkoJ+cQH/jPCC+lyelQMgVZnY7amu2lshr6JBX8vcQzEAakWBBzmOHOlBZIAejAeYdL5bpe GGOiuk91hJEVyBk16gLOELoCLwM+OSquU8hav8g5JZw1AKH9S20T8oduhLa9C0PO4lMVTHuVHjx GmTmFmSXG94C4cwMdj7+yTGI214yBRrZPveqaYRE5opxm9VvpKlMyBxSJWUWKFXdns9PGLzh5+N a+YjLkonW6Qh/ubAg4xU1EcdqegUi3Sn1LgRYKuacNWsQihL/ane7OngTygFzJAKJaWjGrvL2G+ WVSvfm8IePqk84pglJzRx+Ewm0eJsKVBtyDEotnkQ0CY8Pk2BHJUTROygilE3DVweusitq1XssX CSo9V8+UEFQi7SzHO4NHXSNwnxOV/luPYDaEKJLshPTD1hUKc95QPwN+/wKpWAfGNyOIE9x7FLB BPvGO6MaJuXB4DK0c7F X-Received: by 2002:a05:6214:c2e:b0:895:4b79:83a5 with SMTP id 6a1803df08f44-89979e1bb72mr293888636d6.5.1772129215103; Thu, 26 Feb 2026 10:06:55 -0800 (PST) Received: from rowland.harvard.edu (nat-65-112-8-51.harvard-secure.wrls.harvard.edu. [65.112.8.51]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-899c6fe55cesm23138596d6.0.2026.02.26.10.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 10:06:54 -0800 (PST) Date: Thu, 26 Feb 2026 13:06:51 -0500 From: Alan Stern To: Harry Yoo Cc: linux-mm@kvack.org, Dmitry Vyukov , lkmm@lists.linux.dev, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Joel Fernandes , Daniel Lustig , Akira Yokosawa , "Paul E. McKenney" , Luc Maranget , Jade Alglave , David Howells , Nicholas Piggin , Boqun Feng , Peter Zijlstra , Will Deacon , Andrea Parri , Pedro Falcato , Vlastimil Babka , Christoph Lameter , David Rientjes , Roman Gushchin , Hao Li , Shakeel Butt , Venkat Rao Bagalkote , Mateusz Guzik , Suren Baghdasaryan , Marco Elver Subject: Re: [BUG] Memory ordering between kmalloc() and kfree()? it's confusing! Message-ID: <9240040d-598e-48bd-b802-bf91cce92d0c@rowland.harvard.edu> References: <9dcd02b9-42da-455d-aa08-165e6ff0b921@rowland.harvard.edu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Feb 27, 2026 at 02:11:49AM +0900, Harry Yoo wrote: > On Thu, Feb 26, 2026 at 11:42:02AM -0500, Alan Stern wrote: > > On Fri, Feb 27, 2026 at 01:17:52AM +0900, Harry Yoo wrote: > > > On Thu, Feb 26, 2026 at 10:45:55AM -0500, Alan Stern wrote: > > > > On Thu, Feb 26, 2026 at 03:35:08PM +0900, Harry Yoo wrote: > > > > > Because the slab allocator itself doesn't guarantee that such > > > > > barriers are invoked within the allocator, it relies on users to > > > > > do this when needed. > > > > > > > > It doesn't? Then how does the slab allocator guarantee that two > > > > different CPUs won't try to perform allocations or deallocations from > > > > the same slab at the same time, messing everything up? > > > > > > Ah, alloc/free slowpaths do use cmpxchg128 or spinlock and > > > don't mess things up. > > > > > > But fastpath allocs/frees are served from percpu array that is protected > > > by a local_lock. local_lock has a compiler barrier in it, but that's > > > not enough. > > > > If those things rely on a percpu array, how can one CPU possibly > > manipulate a resource (slab or something else) that was changed by a > > different CPU? > > AFAICT that shouldn't happen within the slab allocator. > > > The whole point of percpu data structures is that each > > CPU gets its own copy. > > Exactly. > > But I'm not talking about what happens within the allocator, > but rather, about what slab expects to happen outside the allocator. I understand. > Something like this: > > CPU X CPU Y > ptr = kmalloc(); > WRITE_ONCE(gp, ptr); > if (p = READ_ONCE(gp)) > kfree(p); > > Yes, it's a crazy thing to do. CPU Y isn't guaranteed to see > up-to-date version of object content or metadata. > > Instead, the code should do: > > CPU X CPU Y > ptr = kmalloc(); > gp = smp_store_release(&gp, ptr); > > if (p = smp_load_acquire(&gp)) > kfree(p); > > One reason that I started this discussion was to argue that we should > have a well-defined a contract between the slab allocator and its users. Yes, you have made that quite clear. But you're missing _my_ point. Which is: The same mechanism that the slab allocator uses to ensure that CPU X and CPU Y won't step on each other's toes if they both run kmalloc/kfree at the same time should also be able to guarantee that the metadata changes made by CPU X will be visible to CPU Y if Y manipulates a slab that X just finished with. To put it another way, ensuring non-interference during simultaneous accesses isn't all that different from ensuring coherence during sequential accesses. Doing the first should easily allow doing the second. And if it doesn't then something questionable is going on. Alan Stern