From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 D7379A55 for ; Sat, 23 Mar 2024 02:26:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711160796; cv=none; b=HAbBg2ZxXsTyXQjqFwgqwWl4caAmZLKJrBBqB6z9Gdc1O+N6ZDD0doOYfruGF171ZOgW9PHKIZnESnDdySlVO8VD6o01K2J8+8h6FZooE8O+WEjeZw5QsAjjippVbpEMmIeBYzj2pmSWgs9uB9Ac9UCzsWqm6VtVja/4Q3htGII= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711160796; c=relaxed/simple; bh=GLL8pdx2fKWkkU8matEFO89Wac2DtH6pOejmSxXEEII=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Xovbd3Xw/LInxQez58KVwCBrjx4IyyOtNDz0A7cQEORffKccgLVpAzZOcv1bobxkWMJrK7iIVXaaOkD6FvPlvbTKXi+HZyBk6GUKCNArGfFS5MCH7cUolk/XLNimD+bImzph8xoXkLh5C+3bGWgR7FsjXUYa2MXvcvSwJ1LRanw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nBdfJA9P; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nBdfJA9P" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-69185f093f5so20833556d6.3 for ; Fri, 22 Mar 2024 19:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711160794; x=1711765594; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=AXWJvJZ+9VsV3RQHdz7GElkYKlzfacUvA+hl5w+A2pc=; b=nBdfJA9PEBKLLNWb7yTJ3clTrpuRf0vt005Dc6nJE2xxL2R0nOcvruU3cnFR6FqP/4 ZspAzDilKSnUbtYE4tZsArslUBeqrPZv4DddPWcGswNYU8R0d2txeOr/oeLHIYDFp032 NqqePKkCjgHmWp9DqN0lix4Xp7skJDkKO2STCXiR+HgDScu8si407qIRP5NjLBev9t42 sy6CEMJR8/b3aodOTOrZJGU6y3Q1mNyPKnB1qVoeUoi8QG6uEsmf3qy9RrKua8nwzHq+ 71BYgK5SNFNDhnaHkbfW0v9kMC2wfYWbNlFUrpzOSn/GZvK0Gktl5wQBZ6fsdVkDri48 UW+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711160794; x=1711765594; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AXWJvJZ+9VsV3RQHdz7GElkYKlzfacUvA+hl5w+A2pc=; b=PGNDG2kuCMbwa3QxM6l3RSBGb7VNud/a2OKnNEfi77V8L1KCsbgqMhoFTMtakRZMMp UbB/yVtfiRmgJRUygdfp6PIKSbaswnA0cIzbYcGpEHwwuUoSUd9Gz6Zmhc7+0l/dp+m2 pCXmpCni9udDQ2Nlelo1l8+H0gR5cL904lBhElea2oSI/RJ6DGKYwQX1umJnttUY31lc Fj+ID0Jl20KhECqEDltgRvtthvbY2lqLTQ28EgRSDQC1TvZFPo0y5e2c51+TvIjSnJtC YDnu8Ets+egA8cbnQ6pm2H3hc1hzUJNrvY+RO7oEj7EqQXMLOJGJLNIGZmL1baWJLMo2 MR1Q== X-Forwarded-Encrypted: i=1; AJvYcCUVCZhwPQb3mdhj7ZVMAcaNHJ8to85Y7rHj7TDXLVuV3qsslmZA9U8COKeuJbLP37BHXkloR+K1A2/dmrDme+AaTVGgwg== X-Gm-Message-State: AOJu0YzHV/26Fq5tKZGCtMBro+b4oXxvbYQr+Z6/oKjfDozhNGVilkj8 ApaiZXGPK465AHMFwSNUyeYeDSaLJis+KMJpB4wYFInQape/uv3v X-Google-Smtp-Source: AGHT+IHRua83/etcjWUTeOkd74S4PqwJUvYuzFevBWbUwWMqvkHnncpQsqfVM6o+HXolWLggxGI6EA== X-Received: by 2002:a05:6214:2522:b0:690:ca82:55f7 with SMTP id gg2-20020a056214252200b00690ca8255f7mr1378038qvb.19.1711160793765; Fri, 22 Mar 2024 19:26:33 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id jo14-20020a056214500e00b00696769860ffsm463893qvb.99.2024.03.22.19.26.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 19:26:33 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id 5A8DD1200066; Fri, 22 Mar 2024 22:26:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 22 Mar 2024 22:26:32 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtfedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeejiefhtdeuvdegvddtudffgfegfeehgfdtiedvveevleevhfekhefftdek ieehvdenucffohhmrghinheprhhushhtqdhlrghnghdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsoh hquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Mar 2024 22:26:29 -0400 (EDT) Date: Fri, 22 Mar 2024 19:26:28 -0700 From: Boqun Feng To: Kent Overstreet Cc: Linus Torvalds , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , kent.overstreet@gmail.com, Greg Kroah-Hartman , elver@google.com, Mark Rutland , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [WIP 0/3] Memory model and atomic API in Rust Message-ID: References: <20240322233838.868874-1-boqun.feng@gmail.com> <3modld2dafaqjxa2b7jln47ws4ylzhbsvhvnphoklwvzange5p@wlir7276aitp> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3modld2dafaqjxa2b7jln47ws4ylzhbsvhvnphoklwvzange5p@wlir7276aitp> On Fri, Mar 22, 2024 at 10:07:31PM -0400, Kent Overstreet wrote: [...] > > Boqun already mentioned the "mixing access sizes", which is actually > > quite fundamental in the kernel, where we play lots of games with that > > (typically around locking, where you find patterns line unlock writing > > a zero to a single byte, even though the whole lock data structure is > > a word). And sometimes the access size games are very explicit (eg > > lib/lockref.c). > > I don't think mixing access sizes should be a real barrier. On the read Well, it actually is, since mixing access sizes is, guess what, an undefined behavior: (example in https://doc.rust-lang.org/std/sync/atomic/#memory-model-for-atomic-accesses) thread::scope(|s| { // This is UB: using different-sized atomic accesses to the same data s.spawn(|| atomic.store(1, Ordering::Relaxed)); s.spawn(|| unsafe { let differently_sized = transmute::<&AtomicU16, &AtomicU8>(&atomic); differently_sized.store(2, Ordering::Relaxed); }); }); Of course, you can say "I will just ignore the UB", but if you have to ignore "compiler rules" to make your code work, why bother use compiler builtin in the first place? Being UB means they are NOT guaranteed to work. > side we can obviously do that with a helper; the write side needs > compiler help, but "writing just a byte out of a word" is no different > from a compiler POV that "write a single bit", and we can already mix > atomic_or() with atomic_add(), with both C atomics and LKMM atomics. > I totally agree with your reasoning here, but maybe the standard doesn't ;-) Regards, Boqun