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 18F06C54E67 for ; Sat, 23 Mar 2024 03:51:30 +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=Mv6fBpHQPcgPm0D9R2qsAP2e7sQKg3ZHVHi31ICM9OY=; b=wZPAdJQ+f8Mvde lxGJv59TxvXKFCi/gr7lddwtz7I7TPcWaBPFpXE1KnXaFFSnb5mZBHXBtzPNp1AGlJ8HVzSdGHhoR 1xGPJt5nJy68eULrX2Ifi8R2SjJTtYue8yHFmNjUn8ZBonWgpxNPfctPHA2HthHVv2ski7O96ykIQ LMxEjEm40S4e3jVFLL+UN2YALMOukGwPRl3GNCc8W14T0S38nHfUTZfEk0wmCQAQOS8iCveDrLX+3 +G8Thv0+KxIiV1vPrmVmsg42mJM7DA3SB1bCH61/xCl+pkn/2Bx529GNfraHjPi8TOeADwWkmslFW SpJy+XJx2upLiHfoWd/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnsPe-00000009NUF-43qx; Sat, 23 Mar 2024 03:51:18 +0000 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnsPW-00000009NQA-3MUj for linux-arm-kernel@lists.infradead.org; Sat, 23 Mar 2024 03:51:12 +0000 Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-429de32dad9so18371751cf.2 for ; Fri, 22 Mar 2024 20:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711165868; x=1711770668; 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=fthf99+C6r59SY0f1P7eO/8dux5VEEpV4VML7N7nikc=; b=h9F8uKwZEWu6P+ClmmfWKdf1Mti/QZVlwXXRvmk7GChLw6aiUbr73+PaxQp/aW61fN xZRa0nfQKRNE5arvfR1aPhlFng9EFWlXlZNpDNBl4la5hQzCzB5ABWTy9GOOPcGU2IFt OhW7czwTv5/axXcfyXYYqNc3ZM4owPeWLRIXvqhToJYvqMRT55XXh8KfQ2WLeyyewYx7 tPMPvNyir5Bp0YxI8+35McJO9EbqHQMdIT68PiXfAaTLvOS0A7ADwoQsxbYwFTmx1p7J BchE/NWD176LuRLjvXAyKhvsAZh0GANKoMKx4NPyoccyI0CENs+x9ewZeRUy1mA192fT LgFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711165868; x=1711770668; 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=fthf99+C6r59SY0f1P7eO/8dux5VEEpV4VML7N7nikc=; b=wwPDlq2Pfavu39hZW1J7FZxFD7fV4uTbARCfxf6ONuuUPmDfSb28d/5aFHzV8tXkVM oOcUIalf8hlugkn0OnoI+qTBLI+50FxicBmyJ01jRmYw3KwMiqfs0jAP+/uC64gGYTNU yvT/KClq5xguz8NNz+JRWgBSzLL6Me6kMgdmfHK4dWVE+UZ+n/nhWVn7CrdVyhooosHT VuM3n3uAd9M4lLX3w/Al+n2UMXXZ/Dydiuib7FLnwobhMJf62KPPJB8JKxjdHrxgCrZu 3L6Fhsz0hmAwmHNG3oD2+POcqHPfXNv/vZxN44UY58Uqy3TEOzL7LGI71Cz9y4EqSfom 1HcA== X-Forwarded-Encrypted: i=1; AJvYcCVZ4cIcH8gYMEj/g9xOAjDnL4ts9CX/0saUDlHQd5j/0Ep7MdA3mP8HIGR239rV+aMelSYF6HN2LOKMorNsRBxG9VqKHQDEx3vCxE/Tb/Jj0rqE4gI= X-Gm-Message-State: AOJu0Yy3IlTik4eryOCLKd+fdWaI/LRYRERZjjlSnmPSzMGfG+dEsOXh F1orvq90BsFI+q6AtwnzSD8KAdj9Kf0gNuSMOjkAN1o6iZVcJ+yx X-Google-Smtp-Source: AGHT+IFD4uxS5AVpTZ118zy+ZVLuALlh6ZcR9Zu6I7AtHzgx0POKa9T0KapT+m3+rTw73sgKM4TITw== X-Received: by 2002:a05:622a:1991:b0:431:2033:d4cc with SMTP id u17-20020a05622a199100b004312033d4ccmr1554788qtc.21.1711165868328; Fri, 22 Mar 2024 20:51:08 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id u15-20020a0562141c0f00b006914fd6b64dsm1720995qvc.127.2024.03.22.20.51.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 20:51:07 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id A9D9A1200069; Fri, 22 Mar 2024 23:51:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 22 Mar 2024 23:51:06 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtfedgieegucetufdoteggodetrfdotf 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 23:51:04 -0400 (EDT) Date: Fri, 22 Mar 2024 20:51:03 -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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_205110_905208_5E7233A9 X-CRM114-Status: GOOD ( 32.06 ) 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 11:10:36PM -0400, Kent Overstreet wrote: > On Fri, Mar 22, 2024 at 07:57:20PM -0700, Boqun Feng wrote: > > 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. > > That's casting - that doesn't work because compiler people hate > aliasing. > > But intrinsics for e.g. > __atomic32_read_u8(atomic_u32_t *a, unsigned byte) > __atomic32_write_u8(atomic_u32_t a*, unsigned byte) > so "byte" here is the byte indexing in the u32? Hmm... I guess that'll work. But I really don't know whether LLVM/Rust will support such an intrinsic... Regards, Boqun > should be doable - that's perfectly fine for the compiler to model. > > That would admittedly be ugly to use. But, if Rust ever allowed for > marking any struct up to word size as atomic (which we want anyways...), > it could use that under the hood for setting a member variable without > cmpxchg. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel