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 DD3DDC47DD9 for ; Sat, 23 Mar 2024 02:57:57 +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=Mtup7RgEqnObI1VsFx1mSl84hbyfMQ8dKdFX0w//m/Q=; b=NmKxhgM14zCbRY HzKzq5ERn1JXDq78GjQGufgxmXviyWwpdlqQQRnv2kxHRnpX1FDvVJPZ5HxNfXKXaT5K3BGuHjItt bQoJSkl9XAGrq4MfzQFfzJ1OwkMyP90nfXU9suIp2viAdtzBLD1ImmH8Xk3Prsu9x37Pr08J3DyTP ezC55yDLTMcz0xhgx5rR+/oNISI+jI026R2X+4t9zqIypzI3Uh/dX/R+MprgI6HUQo+JgajjhrKjh K8rOvMnqCbJui7ycZV9DHSMaoPG1IoREYbd/rAMgsq4JYsoHQv9uAkv9anYrjfRW0klICxjPQkpYX 7MrDG773HHfu7SUwG2ww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnrZk-00000009I8o-4A98; Sat, 23 Mar 2024 02:57:40 +0000 Received: from mail-qk1-x733.google.com ([2607:f8b0:4864:20::733]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnrZg-00000009I4J-3fdZ for linux-arm-kernel@lists.infradead.org; Sat, 23 Mar 2024 02:57:39 +0000 Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-789e209544eso165866485a.0 for ; Fri, 22 Mar 2024 19:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711162646; x=1711767446; 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=kpSl8o7jNHU35uGRWAm6lGoxX/v+3hFWNREiHEQrRxE=; b=LHjLitipqmse34wZJLH4YMfVgC8ijEmC/iHITDxNSk01kLXYWHXYofnjMMy43DdPu6 7uuus3tty9k6p1wXfekozzyjJMoA8UoawYLNi3bDtLgny3LVVTY++L1nPxXv0blS2UzD rQ6c/c22KY1pmsyZgMN3izoGK7dJH3j7BdRrSlr0YrMRBoNAtVGknHeT4BvP7iib+R3u C3PdsQ9xCP3ZLdEoRvRacR8QqLMPMEQowzkLroJPkwoOoTq30P7s7tc6qEq6G4cZ/jgX gaU0hztvk6Ha6jqT8LN45CVALvcCx/7PPDwwT6dd1sp48B46jxIdeep4jTN/Jm63DTUR 6kEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711162646; x=1711767446; 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=kpSl8o7jNHU35uGRWAm6lGoxX/v+3hFWNREiHEQrRxE=; b=lB370oZ78st/b4zFTUrP0DlD623QQoWAGVJUTW4OyTQ07/YaWDVisWz6NX3YNTMU6r bEjhc2eEqDw8BIJpjcmrWoZuS64OMNKSXWT1YtA9aNhNAbLo8FrV/9YuJFXlLC63PznS iHqjVWRjWKLrAD5NRdHr4qCXHABd6l9doyTV1LmMsS/viNTY8RFqKHNdkNe9EAUrlnb0 li0ecPGEZ4i+EnFw86wkxBrC2ZpteAXUhOX3ijTaf0Pr3DuNR74ZeZpHv9aiTlmtBdWV kOHzM14tqOT9hWI95afTaiOzTTaFqWa5F/uFL/NARKSP2tFsrDJbSzhW+Jexrd/v2H0p PzDQ== X-Forwarded-Encrypted: i=1; AJvYcCXD/Brw+FCX5ozkY7enkD3dXIJ0gszirKJJt4tzhP6LsooQiMmM1HBdVBGyScQC3TZMl/ewaYC7hSys1COMjjt4sxyCIZCD+j8ot5uQidqt1OMNjkI= X-Gm-Message-State: AOJu0Yz8LBmt4d3x7ivF1LIoT+9WYIuyVXQJvEGTRCml3m37TkWvVRbW +jEd92l0cykBYilmEeiU+HkJYU81Hbq/KRP1M6mRewWYsp25wDEo X-Google-Smtp-Source: AGHT+IFGkguh6CxSo1IGeVd0RUnDbg2suvzRZLhnT/eomKsCIq41qcusHAcYijHLmqEB7POPWFAOKg== X-Received: by 2002:a05:620a:a93:b0:788:12af:3f0e with SMTP id v19-20020a05620a0a9300b0078812af3f0emr1255744qkg.56.1711162644512; Fri, 22 Mar 2024 19:57:24 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id h26-20020ae9ec1a000000b007886b695939sm363844qkg.118.2024.03.22.19.57.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 19:57:24 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfauth.nyi.internal (Postfix) with ESMTP id 1006A1200066; Fri, 22 Mar 2024 22:57:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 22 Mar 2024 22:57:23 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtfedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeevvdejffefgeffhfelffeikeeigeehjeekgfefudeugfejfefhteekvedu teelhfenucffohhmrghinheprhhushhtqdhlrghnghdrohhrghdpiihulhhiphgthhgrth drtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtd eigedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehf ihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Mar 2024 22:57:21 -0400 (EDT) Date: Fri, 22 Mar 2024 19:57:20 -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> <34r4signulvsclmsiqgghskmj5xce3zs5hwgfulzaez2wdyklr@ck6zrj732c4m> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <34r4signulvsclmsiqgghskmj5xce3zs5hwgfulzaez2wdyklr@ck6zrj732c4m> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_195736_951434_0CF3390E X-CRM114-Status: GOOD ( 24.24 ) 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 Fri, Mar 22, 2024 at 10:33:13PM -0400, Kent Overstreet wrote: > On Fri, Mar 22, 2024 at 07:26:28PM -0700, Boqun Feng wrote: > > 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. > > That's not what I'm proposing - you'd need additional compiler support. Ah, OK. > but the new intrinsic would be no different, semantics wise for the > compiler to model, than a "lock orb". Be ready to be disappointed: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/is.20atomic.20aliasing.20allowed.3F/near/402078545 https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/is.20atomic.20aliasing.20allowed.3F/near/402082631 ;-) In fact, if you get a chance to read the previous discussion links I shared, you will find I was just like you in the beginning: hope we could extend the model to support more kernel code properly. But my overall feeling is that it's either very challenging or lack of motivation to do. Regards, Boqun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel