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 C9577C47DD9 for ; Fri, 22 Mar 2024 23:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=hrBZg/A8IJZ/5uDX04SpiJoKWummJYY8cuyBhhO2ZpI=; b=Te5S9PVVozLhg2 yJ7UxSVLnBGd6ttwasp5HE/yZuA7RNz0RnG3sEIZFyoaN0jNIcd4LfydpXW2wHVSgCoShc55J+cC8 8TBuEQQ3dvWPQCcMtIDun7la+rredoQN13OPENWzt26TR12etTLCzwY1W7WZjBglFZvzA+cNL1I3K UFC0TNcwEEI8qizwX6AwwjRjjRGTDZ+iOG1L+POmEvK/aM9Ayu7lMh1HYNZWK0xoIQo6iIZIbvuiJ a7qJXhsPZnwIRZ9DIEWsctlZtYFC9kAX2xJXHO8O7GvmsLizr4KaQ3tPYBStirEVSUdltIonZPHw2 S9Wae16qZ1wx63WzGfyQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnoTh-00000008vqa-0X7s; Fri, 22 Mar 2024 23:39:13 +0000 Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnoTe-00000008vpY-07ea for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 23:39:11 +0000 Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-430c4e67d40so18317641cf.3 for ; Fri, 22 Mar 2024 16:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711150748; x=1711755548; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:feedback-id:from:to:cc:subject:date:message-id:reply-to; bh=ihthLhUKDez7apre5WNcowgmLHfDAeuMZ64Fs/0tAkA=; b=F5QFMEIZSpK78ZJAGBBJljiV9hwB5OzAcvUg0MJjCgIn78lHpb3DjSf1R6XQdple7a crxldYTUDEkbfNgX/6ZfSLAEcppb/5DePOf+QQ5s/YBKiIp88K9uS0feBcZS9u9cGtTF 4DVEmZcTw2xiH6g5K+zQT+DUrgx+l+4BoZYze0p3mqfWblRNQaR7IxW1ulXuomg5M68x bkQDYWfprctF21ftoSC9JjfT+dXbh0N3xpCyt6R5yuqtC17TFY+B01roSGRRParhtFAQ q/3EycKcXScirNWULUXBDVtqkc3Nnsx1qh54aQcdHA1o8MqBgyQeMBrtcYHIxGGBVhbN wqGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711150748; x=1711755548; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:feedback-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ihthLhUKDez7apre5WNcowgmLHfDAeuMZ64Fs/0tAkA=; b=qoZidbQ/YOFbUOxuS9MNPpGllFPW+TLAZIyDRaMJgrGbcYvAdIMdGVQ3xuVvOQZtur V5fe8ZKMy7ZOHtn+g4QZvY1WCJ4miflzJnXJy7xr0rK3RsoLUoWsTE2rqSYFkclu8G4S 1Hy5XWp3+5ziGkrGYEIYN9jzoKkEKP1uTSndnWtji/SxWc19cCgJveUy2/1rUsg79Zfp 7OoneP5b8JNqaH5axl0pabuoFYMVZSvwYPcnmPm6+1mm3q3WABX8F4tNdw+3rbAZZ6Xy wKq3Z0G4PCVPw0b/tNIfxOKApi2rLQ0PhH0AtGZDYmNHEhbbfZWmhNYvYQUQMvkxfhcW fUKQ== X-Forwarded-Encrypted: i=1; AJvYcCUOu18s1jMPGB2MvY6rcMiI2hV5mPbL0bJL+sKHbz4fE45P8Lvl2amaskFKxkNodHq+tdc5lrz15Xgo9/zDYim2X1MgKdw/BYVGODv4FJcs+EO/jQY= X-Gm-Message-State: AOJu0Yxops/5rGlzEUiDLbO7YXsMFO0n4l0630pVy0imcw//9xuPJsVs 8WtzK5QTO3kiITNZVvjUe2rX0ACKYfWeymn7k+yS6D9xZJYHdX1T X-Google-Smtp-Source: AGHT+IEtxqGn3kAtIV4D96rJILpY2Sr7kOPlyrqC9vZdift3MfB5dK3Ly5o2AHSrAoeMz8EZNAQnbw== X-Received: by 2002:a05:622a:5b89:b0:431:3d52:2fdc with SMTP id ec9-20020a05622a5b8900b004313d522fdcmr874851qtb.65.1711150747498; Fri, 22 Mar 2024 16:39:07 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id g26-20020ac84dda000000b00430b3fbfeb3sm285249qtw.47.2024.03.22.16.39.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 16:39:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id D8C561200032; Fri, 22 Mar 2024 19:39:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 22 Mar 2024 19:39:05 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtfedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgggfestdekredtredttdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeeivdevvedvffejuedvudekfeeltdeguedtleetudehudfffeejvdelkefgueeh ueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhruhhsthdqlhgrnhhgrdhorhhgpd iiuhhlihhptghhrghtrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlih hthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhm rghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Mar 2024 19:39:02 -0400 (EDT) From: Boqun Feng To: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev Cc: Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?= , 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 Subject: [WIP 0/3] Memory model and atomic API in Rust Date: Fri, 22 Mar 2024 16:38:35 -0700 Message-ID: <20240322233838.868874-1-boqun.feng@gmail.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_163910_096621_0E97B395 X-CRM114-Status: GOOD ( 22.57 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, Since I see more and more Rust code is comming in, I feel like this should be sent sooner rather than later, so here is a WIP to open the discussion and get feedback. One of the most important questions we need to answer is: which memory (ordering) model we should use when developing Rust in Linux kernel, given Rust has its own memory ordering model[1]. I had some discussion with Rust language community to understand their position on this: https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557 https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992 My takeaway from these discussions, along with other offline discussion is that supporting two memory models is challenging for both correctness reasoning (some one needs to provide a model) and implementation (one model needs to be aware of the other model). So that's not wise to do (at least at the beginning). So the most reasonable option to me is: we only use LKMM for Rust code in kernel (i.e. avoid using Rust's own atomic). Because kernel developers are more familiar with LKMM and when Rust code interacts with C code, it has to use the model that C code uses. And this patchset is the result of that option. I introduced an atomic library to wrap and implement LKMM atomics (of course, given it's a WIP, so it's unfinished). Things to notice: * I know I could use Rust macro to generate the whole set of atomics, but I choose not to in the beginning, as I want to make it easier to review. * Very likely, we will only have AtomicI32, AtomicI64 and AtomicUsize (i.e no atomic for bool, u8, u16, etc), with limited support for atomic load and store on 8/16 bits. * I choose to re-implement atomics in Rust `asm` because we are still figuring out how we can make it easy and maintainable for Rust to call a C function _inlinely_ (Gary makes some progress [2]). Otherwise, atomic primitives would be function calls, and that can be performance bottleneck in a few cases. * I only have two API implemented and two architecture supported yet, the complete support surely can be added when everyone is on the same page. Any suggestion, question, review, help is welcome! Regards, Boqun [1]: https://doc.rust-lang.org/std/sync/atomic/#memory-model-for-atomic-accesses [2]: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/LTO.20Rust.20modules.20with.20C.20helpers/near/425361365 Boqun Feng (3): rust: Introduce atomic module rust: atomic: Add ARM64 fetch_add_relaxed() rust: atomic: Add fetch_sub_release() rust/kernel/sync.rs | 1 + rust/kernel/sync/atomic.rs | 65 +++++++++++++++++++++++++++ rust/kernel/sync/atomic/arch.rs | 15 +++++++ rust/kernel/sync/atomic/arch/arm64.rs | 46 +++++++++++++++++++ rust/kernel/sync/atomic/arch/x86.rs | 48 ++++++++++++++++++++ 5 files changed, 175 insertions(+) create mode 100644 rust/kernel/sync/atomic.rs create mode 100644 rust/kernel/sync/atomic/arch.rs create mode 100644 rust/kernel/sync/atomic/arch/arm64.rs create mode 100644 rust/kernel/sync/atomic/arch/x86.rs -- 2.44.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel