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 3DC45C47DD9 for ; Sat, 23 Mar 2024 02:26:58 +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=e6q/qDMH28Ziw2WxM4xueajxfr7O+h5y5+bdJ9VFpFE=; b=toRCbjLlggcpMV 9daKbk3Ij1Y4CaTjtixE3uLNlKsrf4r/oT2L4zTrrAWQaISlk19WnE+OeuGSa/pOJAnt3J7Js9Qlw 3rqgwlwLlZvUP/oSjdvqFeZ0+kGFcZrpA7GeAJXBQMWiM4VDvm9kYrjqw6GXOgbyeZjvSw2xr65S8 F65lK9dA4AmDdPz+NjkOfmtHPz+SA0COl7N6gG4UV789+v2P/F8VKFNlE4rhR8r7jdqpjvcwkvBpt WNwe8Fg2rb1OIBCTu3KLzTDqWdDXqk0Oaiw1kxfiFAHoDa/T+1mMVLw4JWgDLbmL8ZTDOCk42YQbL JcZbNwjwG9nYTSobYeag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnr5n-00000009Epw-2Z30; Sat, 23 Mar 2024 02:26:43 +0000 Received: from mail-qv1-xf2f.google.com ([2607:f8b0:4864:20::f2f]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnr5j-00000009Emv-32ur for linux-arm-kernel@lists.infradead.org; Sat, 23 Mar 2024 02:26:42 +0000 Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-696147fb5a7so25746336d6.0 for ; Fri, 22 Mar 2024 19:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711160794; x=1711765594; 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=AXWJvJZ+9VsV3RQHdz7GElkYKlzfacUvA+hl5w+A2pc=; b=iO8SgELmUcrDgw/Zc2MpyQpgknt4zE2tke8H+KQyEUCasfg9OUUUQ1bmywFZFoXucb +mX5mcsbJGM4vJYSIyN7JWNLCLo3OhfnmfokoQ2/A9fXF6Db74m/ZGq0ptrqmVmURXf5 d9+u1jfMPCwRCpabX4rkn0UO5mM2ahTRHjPuP/BLneF0K6n15T4G4se8J7Vsx0Bkyesh yEgP0iprBc6pcBqQgdofTYEs7wZgsYPd5x2MaR8O9T62GsQgTS1nM0ROmxAubkMkbybZ xqrrLXmGi/3C9NaVnlDDTTX1K0XoZPUoVzr8+2/580QC6kBuDEAlK8ZQo9pBuZDTIG/m RP5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711160794; x=1711765594; 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=AXWJvJZ+9VsV3RQHdz7GElkYKlzfacUvA+hl5w+A2pc=; b=TuEqASwpQMhDDB/Rlbm96oq/0mqymFJvAJvAXdsIufnHi3CjKPM/7Gq4yyEsSzc8UE UigACLCWY01DDAZkY7F3e+V5DJ7RhL6xJoADSem4FaxO3anmNZ0LNc9DrQMt1CEpKn0u cClmzPJ3+JpMZOXutjfY7e9n5LNTi/DOpKZnkdqKx4e88OVCWUgv2R1797rXpyZ/zYZi YYbxwayujs481DXvQzq0GLMYgYo85NK9RTCMIQZUyJsn42vvCrDGufaOGIfR1EjdVINO gQPM/6sgSXJBVd0qgpvYqQ7cw2ku+Tn6K00OHJe24OtVvmXgTcx88MO0Rp51cc/6N0CR 9GLw== X-Forwarded-Encrypted: i=1; AJvYcCUc24m7xAoEwiTxM+ILgX+r/lSpTbj+4Eng122Z1EhuHeepJqDgSvxiDCm25XcP7SyUF/AQREjVjKuPTyLn9teGmw3GpXnIzte5y8Uot6uttLCIDic= X-Gm-Message-State: AOJu0YwojFdtPjhVOSBHSt/i00oDBmRfyb4LWJr0OJ1dB3txskHuYV7p u/3f5V8Cssk5HNV3rQpdOGlQoEdPhpvWgiKaNY5Wsfhk5aj1rez4 X-Google-Smtp-Source: AGHT+IHRua83/etcjWUTeOkd74S4PqwJUvYuzFevBWbUwWMqvkHnncpQsqfVM6o+HXolWLggxGI6EA== X-Received: by 2002:a05:6214:2522:b0:690:ca82:55f7 with SMTP id gg2-20020a056214252200b00690ca8255f7mr1378038qvb.19.1711160793765; Fri, 22 Mar 2024 19:26:33 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id jo14-20020a056214500e00b00696769860ffsm463893qvb.99.2024.03.22.19.26.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 19:26:33 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id 5A8DD1200066; Fri, 22 Mar 2024 22:26:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 22 Mar 2024 22:26:32 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtfedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeejiefhtdeuvdegvddtudffgfegfeehgfdtiedvveevleevhfekhefftdek ieehvdenucffohhmrghinheprhhushhtqdhlrghnghdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsoh hquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Mar 2024 22:26:29 -0400 (EDT) Date: Fri, 22 Mar 2024 19:26:28 -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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3modld2dafaqjxa2b7jln47ws4ylzhbsvhvnphoklwvzange5p@wlir7276aitp> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_192639_853252_3675F073 X-CRM114-Status: GOOD ( 18.25 ) 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: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. > side we can obviously do that with a helper; the write side needs > compiler help, but "writing just a byte out of a word" is no different > from a compiler POV that "write a single bit", and we can already mix > atomic_or() with atomic_add(), with both C atomics and LKMM atomics. > I totally agree with your reasoning here, but maybe the standard doesn't ;-) Regards, Boqun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel