From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 8DADB10E5; Sat, 23 Mar 2024 02:57:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711162647; cv=none; b=LHhU1kue9ytgkBVODLQbbCSimMRKKxFKrCAm9sfTljXrNkHzclCv75vNbay1QhyD+SbY6Q3ayTxIUMqV9vURWeck57+6XQZaqiJtrfGGCwz+zS5DuadmKSGhU1nofYc6RkisaeZn6HwbAaNnJStLbNSedJfEV25W9np2rvxc2Mk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711162647; c=relaxed/simple; bh=vpZhcowLAm3Dy6FfbLwUZs3OgFJBOZ6DIZw//2d1m3k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JMv3+EKX5051XwkonLraYiWXWhYIr2k2jgYR3sGI0OUQ1ximGqK4EMiTMdMyPBamYK8bREWT1xnADU5uR+jTv3rVsxCM+ufxYHSdaL3cQeUIMLCVTl6q2kZeeze7XIIof9oSWUDAvVRRTqKZ3fMDRJGnT0n58b5uWSMOkNYhkuY= 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=Nw5ZN0aK; arc=none smtp.client-ip=209.85.222.172 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="Nw5ZN0aK" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-789f1b59a28so183654185a.3; Fri, 22 Mar 2024 19:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711162644; x=1711767444; darn=vger.kernel.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=Nw5ZN0aK7HCFRA9u+ddgaPbKBn6Zxe85nbnyfMVkITRLhThSIOf55ElxEo/1TogED5 DxwYPCwm5VRsjMLOj9YCBzRP8ytiYcOXromCTG83wifXeZTEc5eKTWbH4+LsNgQMQxzz 1bh5Ik0LDc/xKiI7srcAdO/AAfPcR5MKBk8WAy1Sbaw/BQUY8F9kbCssFf8oP1HbmvmG ZtringrOGtdLXs/LPpMVFWh83cgrDsmEZ8zmZfZkYVJAK45OdfuUB6i3pOfnByfUHslK KTFxq1zNuvogiZMD8O7j0xc79gerPZDDYLtaNrPIrASUOEVea2oIbitkX+MLw0ltjfyE Dnhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711162644; x=1711767444; 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=ksHl7UwUB6wTWPRISSt78Meq5ZP9ZX/0nNikWhpkm+57EVZN8JXO6lgCo2MTg1bcdu e3oT83bRSfZGWe3hMUuIEkc+YMrCFw2zqMnaw+EYSHveollMIwbZ+WOdv6zmshdGNdtJ 5YNYBGezAC9EkjN51dJFrZAdytGjYIBAk5bFOmf9q2UPq+T+fe+Jjvhi6Prdmz4K5PC4 vWGYbLSsxzUtJtczQjqz+zT+gDaNUqimeAZF/Ud8EF8waJaW2sQHKB10k3qTKBKWrfn2 1uHbO6JZWMShqiOpX7q/+xDS7HPIqeatcwIs2UxeWwFvDQuv+ArG7rXFXPcD0UZ3vkW6 Y9FA== X-Forwarded-Encrypted: i=1; AJvYcCUskpDvADa27vKrXrSgdTcpskUCbwumtSC4cmkCrk6290lc3BFbtlsb9M9faj5tMvp10K9YEBXuHgSSmQhj2ptsNEC/6Jsfsdi7JfylzGtON6opHrfyu5X4Ix8AtZHVTx/JGYsk7hfYEkL6UbVd6cww4YvKtjLWjv3ZM5bdqwsUpJ5V6FaKNlnHDR2GJsTlRDvYR6K+PKbggQkIORTZwIrpi8TmoMF4wQ== X-Gm-Message-State: AOJu0Yz67gi3NAixf04AaP+paf3MrhUqbpN5XZOQAvD3OORjReT13Gds 9rK49MIdAX7ILLZJ3w6VGETaLBiyDAto+8qu1d2UXaqtM0EHJQaM 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> Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34r4signulvsclmsiqgghskmj5xce3zs5hwgfulzaez2wdyklr@ck6zrj732c4m> 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 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