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 67C80C54E64 for ; Tue, 26 Mar 2024 02:51:33 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RdMB1/9e+SbB+nomoPUPBLvxEb0VXKqVKQFkdMdN8TA=; b=QiDTz84utRoQim zImOl9cV8A59l9eir1ql6evogf0vTHCzXzEfUeA1nJSAezxmMSCi3EhijbbiyMncNjHpfFJ1IwTg2 P+fL8wdl1M0XCAki5gB9/cHu1UmzzfBzEenUDvS527UcjIhohrTBX4PbbFdsxOoreAZjMpMI5tG/V DfWDICPF7TLveKByqbniDcwJE6uBUIYF5QRUgyCy1g5bg4VGxtDheEMj31zdVffFmhrC4LyBdGaNr F+V59EilHxLkFDt9Y8WxL4skqdp9594oTYeHw/4+B/YyyAzlyMO2lLVXdeg+mYAdt6m+eVerMriKs EM9AWanM9HBARz2wbTpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rowuI-00000002pQ2-1MeW; Tue, 26 Mar 2024 02:51:22 +0000 Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rowuE-00000002pNj-1l6n for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2024 02:51:21 +0000 Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-787edfea5adso215235985a.2 for ; Mon, 25 Mar 2024 19:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711421476; x=1712026276; 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=fcNhvrzgAeTv+RtaHHdMdJGRePwYOV19cay72dN5zG0=; b=Uc2ajILoB5T6nQmf2c5UZr8KWc/SF1z1zGq4HB+pPWPrVlvBtnWuLHyCKTZvtknA0b LjlEz8NYei1H8M5stgJBQ1V2BoKjWqNDckb5BOKvSQs2Qg70t8FqdHQZ0yH5SjuDzxcQ asVYOmNqYBinZW0yGTxUbMsVcYyuQdLVK+uLerLHggbSxlNLL4LyNpSJmMLDVk3hmLbq dMTIAJtJbyhQXqe8DbcbqlgUrbjIlnSVbUvhNUclgC7N/+j74gaXY2elNfAfnKb3uQvl zzI8Jt5bCTrW2aGCSBc8kMevcAatxWGYHvNt4gAGkEIq7hcCHIrtm9Vn8qm8j64o0qV0 mx9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711421476; x=1712026276; 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=fcNhvrzgAeTv+RtaHHdMdJGRePwYOV19cay72dN5zG0=; b=m6MM0ENvjehdpl1zwY9eySbTtNVjnYoIGm20ZsJQB9mkdWyBDA4sTXee92vJ/t4Ex6 NhqYuntkdHf1XQ2aEOmLKcR7u/rYniNbjwEgOJfslNy7QHzqKfgqM8b2PsliIAOjlUPj qBtMls+FttQlcsBVk1dxCEyH2Pzq/d4FhelrKi4wlK7IZsBov9pz4mb6VPKFR3tySLBj FNGC5xIkN30h8TBdxvQy129me1O3onfwFO2HjLKtKprYW+1g4DnM+WwHOh7K+lPhmBL3 QYw+J3ZUF84Vto61azI5L3LafVFZTLKyBaJZrmNMN75ktCGVrMZKgCNOo4HQgPpAHo2V J5ew== X-Forwarded-Encrypted: i=1; AJvYcCWj+L3lr1YFFwWW5aEoS7XBLjolDW/rPOuTYV+fRMo7vZlkUvMvVG2mtGgbXG0oEB2WfGGHsaNLC9pQzMB0tPpqGT22fB5ZINKYcbT7eO1OD6kb2VQ= X-Gm-Message-State: AOJu0YwWb55vSKdwHO58ie2Yo8rTTiV4KMq42XKSQYb+w4SNgH/sMT2r nR30zCMEs1UxUBe9VXlmiIpPf/7GZMezUi389rm+kxEi/Yi/0TmB X-Google-Smtp-Source: AGHT+IFDSXtUV4AQwiSzsedITS1Ks+VU5H+aA+IrwzXY0yARA6zx4+/SmU8LSwuDkN0+4uIvx/tnYA== X-Received: by 2002:a05:620a:1d99:b0:78a:45b9:c96f with SMTP id pj25-20020a05620a1d9900b0078a45b9c96fmr8386956qkn.59.1711421476022; Mon, 25 Mar 2024 19:51:16 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id f23-20020ae9ea17000000b00789e800c204sm2642313qkg.62.2024.03.25.19.51.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 19:51:15 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfauth.nyi.internal (Postfix) with ESMTP id 6C02F1200032; Mon, 25 Mar 2024 22:51:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 25 Mar 2024 22:51:14 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduvddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpedvudfgheeikeehiedugfdugfegjeegvdelteeffeejfefgkeduteekgfev keeitdenucffohhmrghinhepthhrvggslhhighdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquh hnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Mar 2024 22:51:12 -0400 (EDT) Date: Mon, 25 Mar 2024 19:51:11 -0700 From: Boqun Feng To: "Dr. David Alan Gilbert" Cc: Linus Torvalds , Kent Overstreet , Philipp Stanner , 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240325_195118_479222_FC8404A6 X-CRM114-Status: GOOD ( 28.10 ) 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 On Tue, Mar 26, 2024 at 12:05:48AM +0000, Dr. David Alan Gilbert wrote: > * Linus Torvalds (torvalds@linux-foundation.org) wrote: > > > > > IOW, the whole access size problem that Boqun described is > > *inherently* tied to the fact that the C++ and Rust memory model is > > badly designed from the wrong principles. > > > > Instead of designing it as a "this is an atomic object that you can do > > these operations on", it should have been "this is an atomic access, > > and you can use this simple object model to have the compiler generate > > the accesses for you". > > Isn't one of the aims of the Rust/C++ idea that you can't forget to access > a shared piece of data atomically? > > If you want to have 'atomic accesses' explicitly, how do you tell the compiler > what you can use them on, and when it should stop you mixing them with > normal accesses on the same object? > Well, you can just wrap it in your own atomic types, can't you? If the atomic primitives that a language provides is access-based, users can create their own atomic types or language can provide via standard library, but mixed usage is still allowed when it makes sense (debug functionality, low level concurrent code that utilizes races, etc.) But if the atomic primitives that a language provides is type-based, then you're limited to what you can do. It might be totally fine as Linus pointed out, if you just write a portable library, and don't want to care about architectural details. But that's not the case in Linux kernel. Regards, Boqun > Dave > > > This is why I claim that LKMM is fundamentally better. It didn't start > > out from a bass-ackwards starting point of marking objects "atomic". > > > > And yes, the LKMM is a bit awkward, because we don't have the > > shorthands, so you have to write out "atomic_read()" and friends. > > > > Tough. It's better to be correct than to be simple. > > > > Linus > > > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ dave @ treblig.org | | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel