From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A17EFC27C6E for ; Thu, 13 Jun 2024 16:31:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=S/xQDUQkQkXZSewCHGCYidY7ntUnzyPAgvU909rXsNE=; b=tJ/xT8kSNKo15dxon9nmzbeJMh JGbOC5yp5fsU8np70/b8wZMqAvu1NxhnpQSJhDKvBWadhkgWpI8JLOWHTUePSjXAtzSsnIdUxTmID bxOA0k0WeCQ0Mr3xFruGvc2cZulKDjVgJf9AcyrghDv7cvUos2EPi+sr0FgiNOzbEsrh4qhmTBKgY +qjwI3aDfZo778JWeHcTct1rJ2kojWJzvHljPVOz7Aac1AuttL4RvqUk6skUnmwhs/vE0IgpLEwnn +gqXgvyUr5rSNjjdv6xy9zvY8BFRDj5cTqpXXtOMxNvyQPWSe5pm12F1/9+nErSzBC37vHqf1rf5T jdhI4vMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHnLr-0000000HM2N-2zUv; Thu, 13 Jun 2024 16:31:03 +0000 Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHnLo-0000000HM1g-457L for linux-arm-kernel@lists.infradead.org; Thu, 13 Jun 2024 16:31:02 +0000 Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6f9b5bc97baso703551a34.0 for ; Thu, 13 Jun 2024 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718296259; x=1718901059; darn=lists.infradead.org; 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=S/xQDUQkQkXZSewCHGCYidY7ntUnzyPAgvU909rXsNE=; b=V+zfkhSbpiE4M9t+jsoCAONIN48KXzVg+LV+RDiTzFHFGPk2rHdrBs/A/Zr9N1SdGx FCWgOt5Is7gkJS1vhg7iLwZauTDMQ4fmh6Ruun3biybCdccR9NJAuikgNCrwOW/eu1at Bj9lUXO6umcdBxIQyHUUXDc+pTW7g40YuwLb30m545jHbNxoReOhu9ECLqpxxDytB2zF DwIu8SMJssjjEgW6TtuvWJEuYZQML6BOdeKumisvGBGnkH5enukRWqSpN4CxFUyXDwq1 Hd/FJuU779J3r0dX3Au1Jw+e2zwc2iE/7H+yx8VXPMgefoaUlK3C8QwfZO5Kb1Mf5Hkt gqOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718296259; x=1718901059; 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=S/xQDUQkQkXZSewCHGCYidY7ntUnzyPAgvU909rXsNE=; b=ImSmMt4Gfq/ds8nYFlOTmC07AEJ7RZFmKNrnC3Bz3lvp6tynlymj+JvXf12R00HmQV bWUbIvUH5UiKMLazgFTBo/q+oGNBdcAycBGySbG3fUaiHGUIuRFf27BNKtk4EMYRi58G Hcwbh1Haz2ryCcQfOetsS6Y4sBqKt06wtRDZP8oaGPjBObnyp1xqX//d98OjxB/DtMtj QEaFCuG6Zk9tqzIvoIWyRArhBobZoSX165e4Y/ETbQCidbejxKET96+XF/p87KTIJ+xw ISHlq0QIg3UTax+6e/BOou9cYvdSSD6aWHnhqRzMDoxP8JQfXaEok+g0wjYEd/gwHX0c pRiA== X-Forwarded-Encrypted: i=1; AJvYcCViInrb/oEqcLlyH/yBj6xovLH/Yg+j83t9TdFi4GsWeEGesQWEO48zzx/YuVAR/8AOklJirczd+Cjy8NKB+s/vb1W1lcB8gTHUL7ckWsfXyaRCQSo= X-Gm-Message-State: AOJu0YwOaTYQRJw/PPCWgLPdn9AZnTMLlOsqeLg3E+L+GzFHXRPuEO1k k31a2hkRBx5e/fi+drr6bOndVxOD3wreZOPDcPa4fh2bRtzTyyyR X-Google-Smtp-Source: AGHT+IHwFVJixei88Rxkp/sFGEHh3v1G3Dr0Ysp8cDcd+fUGWk//eWkUZmoRtez0cWgxv3IlizQUJg== X-Received: by 2002:a05:6830:2018:b0:6f9:89dd:edd7 with SMTP id 46e09a7af769-6fb93b0ee7bmr230805a34.36.1718296258768; Thu, 13 Jun 2024 09:30:58 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id af79cd13be357-798aacc5267sm65463685a.18.2024.06.13.09.30.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 09:30:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfauth.nyi.internal (Postfix) with ESMTP id 177071200043; Thu, 13 Jun 2024 12:30:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 13 Jun 2024 12:30:57 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedujedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtrodttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpefhfefhfeelieffveetfffggeffhfeluddvtedtgedufefgteetiefgjeev ieehvdenucffohhmrghinhepughotghsrdhrshenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhhthhhpvghr shhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquhhnrdhfvg hngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Jun 2024 12:30:56 -0400 (EDT) Date: Thu, 13 Jun 2024 09:30:26 -0700 From: Boqun Feng To: Gary Guo Cc: 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 , =?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 , torvalds@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, Trevor Gross , dakr@redhat.com Subject: Re: [RFC 2/2] rust: sync: Add atomic support Message-ID: References: <20240612223025.1158537-1-boqun.feng@gmail.com> <20240612223025.1158537-3-boqun.feng@gmail.com> <20240613144432.77711a3a@eugeo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240613144432.77711a3a@eugeo> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240613_093101_067113_CC6B9653 X-CRM114-Status: GOOD ( 37.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 13, 2024 at 02:44:32PM +0100, Gary Guo wrote: > On Wed, 12 Jun 2024 15:30:25 -0700 > Boqun Feng wrote: > > > Provide two atomic types: AtomicI32 and AtomicI64 with the existing > > implemenation of C atomics. These atomics have the same semantics of the > > corresponding LKMM C atomics, and using one memory (ordering) model > > certainly reduces the reasoning difficulty and potential bugs from the > > interaction of two different memory models. > > > > Also bump my role to the maintainer of ATOMIC INFRASTRUCTURE to reflect > > my responsiblity on these Rust APIs. > > > > Note that `Atomic*::new()`s are implemented vi open coding on struct > > atomic*_t. This allows `new()` being a `const` function, so that it can > > be used in constant contexts. > > > > Signed-off-by: Boqun Feng > > --- > > MAINTAINERS | 4 +- > > arch/arm64/kernel/cpufeature.c | 2 + > > rust/kernel/sync.rs | 1 + > > rust/kernel/sync/atomic.rs | 63 ++ > > rust/kernel/sync/atomic/impl.rs | 1375 +++++++++++++++++++++++++++++ > > scripts/atomic/gen-atomics.sh | 1 + > > scripts/atomic/gen-rust-atomic.sh | 136 +++ > > 7 files changed, 1581 insertions(+), 1 deletion(-) > > create mode 100644 rust/kernel/sync/atomic.rs > > create mode 100644 rust/kernel/sync/atomic/impl.rs > > create mode 100755 scripts/atomic/gen-rust-atomic.sh > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index d6c90161c7bf..a8528d27b260 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3458,7 +3458,7 @@ F: drivers/input/touchscreen/atmel_mxt_ts.c > > ATOMIC INFRASTRUCTURE > > M: Will Deacon > > M: Peter Zijlstra > > -R: Boqun Feng > > +M: Boqun Feng > > R: Mark Rutland > > L: linux-kernel@vger.kernel.org > > S: Maintained > > @@ -3467,6 +3467,8 @@ F: arch/*/include/asm/atomic*.h > > F: include/*/atomic*.h > > F: include/linux/refcount.h > > F: scripts/atomic/ > > +F: rust/kernel/sync/atomic.rs > > +F: rust/kernel/sync/atomic/ > > > > ATTO EXPRESSSAS SAS/SATA RAID SCSI DRIVER > > M: Bradley Grove > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 48e7029f1054..99e6e2b2867f 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -1601,6 +1601,8 @@ static bool > > has_cpuid_feature(const struct arm64_cpu_capabilities *entry, int scope) > > { > > u64 val = read_scoped_sysreg(entry, scope); > > + if (entry->capability == ARM64_HAS_LSE_ATOMICS) > > + return false; > > return feature_matches(val, entry); > > } > > > > diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs > > index 0ab20975a3b5..66ac3752ca71 100644 > > --- a/rust/kernel/sync.rs > > +++ b/rust/kernel/sync.rs > > @@ -8,6 +8,7 @@ > > use crate::types::Opaque; > > > > mod arc; > > +pub mod atomic; > > mod condvar; > > pub mod lock; > > mod locked_by; > > diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs > > new file mode 100644 > > index 000000000000..b0f852cf1741 > > --- /dev/null > > +++ b/rust/kernel/sync/atomic.rs > > @@ -0,0 +1,63 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > + > > +//! Atomic primitives. > > +//! > > +//! These primitives have the same semantics as their C counterparts, for precise definitions of > > +//! the semantics, please refer to tools/memory-model. Note that Linux Kernel Memory (Consistency) > > +//! Model is the only model for Rust development in kernel right now, please avoid to use Rust's > > +//! own atomics. > > + > > +use crate::bindings::{atomic64_t, atomic_t}; > > +use crate::types::Opaque; > > + > > +mod r#impl; > > + > > +/// Atomic 32bit signed integers. > > +pub struct AtomicI32(Opaque); > > + > > +/// Atomic 64bit signed integers. > > +pub struct AtomicI64(Opaque); > > > Can we avoid two types and use a generic `Atomic` and then implement > on `Atomic` and `Atomic` instead? Like the recent > generic NonZero in Rust standard library or the atomic crate > (https://docs.rs/atomic/). > We can always add a layer on top of what we have here to provide the generic `Atomic`. However, I personally don't think generic `Atomic` is a good idea, for a few reasons: * I'm not sure it will bring benefits to users, the current atomic users in kernel are pretty specific on the size of atomic they use, so they want to directly use AtomicI32 or AtomicI64 in their type definitions rather than use a `Atomic` where their users can provide type later. * I can also see the future where we have different APIs on different types of atomics, for example, we could have a: impl AtomicI64 { pub fn split(&self) -> (&AtomicI32, &AtomicI32) } which doesn't exist for AtomicI32. Note this is not a UB because we write our atomic implementation in asm, so it's perfectly fine for mix-sized atomics. So let's start with some basic and simple until we really have a need for generic `Atomic`. Thoughts? Regards, Boqun > I think this is better for ergonomics. The impl do need some extra > casting though. > > Best, > Gary