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 1BD51C54E58 for ; Mon, 25 Mar 2024 22:39:27 +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=2GExTKQCoRMeGI+r4seO5e4zZ2g9aDZVGTJiis3Irw8=; b=NG9nc0Lid/63bh Z9Pk5ITe57FC4ALdaxcMEX9ZABtCfVauowySFXxSknnoAVMBc49JXK7dl0RsfoWNIOh3BEn57dgN4 JG6WlXCor5R2D+F5ucG7s+27zGU2nnVO0MNg29U74mzhfnzn8y3z/nMWb7WPKwbPn6/QpLkhEWdxy z7XP4p5eSzDN0s+uBjQ9Rx2LMjbk2vo/mbogPR/3fa6Yb+f3kRG/+Zsc7cmsshDa92pf2g/9pWRdp 9yqLBsFkzvLE4qs2VeFVXQclsUIwAGXNzlWNvLnFAbH9rveFDff7aei1Rr478p7meUIpx305ffxjl JnTdYFe82b4L1C+hQRvA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rosyH-00000002ErZ-1Pzu; Mon, 25 Mar 2024 22:39:13 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rosyD-00000002EqI-0adY for linux-arm-kernel@lists.infradead.org; Mon, 25 Mar 2024 22:39:11 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-dd161eb03afso4291341276.0 for ; Mon, 25 Mar 2024 15:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711406346; x=1712011146; 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=DqLcZpfFx6aJ4RsnMU0gGS++kj6ptNsIBWGAoEw1/x4=; b=nDXT82ijvdRFFIrvmOI58U/ETZGHy4u/1KeuphmkC+tGRAgqq3Bu9dFFGiisD9+L29 upX8wGeqFXfaTdYQXT9CoWLM9MekPtXZBIooMhtcL9QHxAMo421i0Ojj6D02KP/Avs9P GOEmD8qmy2zzPE5NbQpqSOSsjFEjAuMvzAkgQ3kwFW1/ytCGMiOX0ojyoDERSWR+OM6d VkGFpDERxU0dXHH5T8DcDYkT/XE1UOB61ElV3rxEa2T5bddotfX1yadnRV+zxlLJLT0I kWArzq0ZnZCCV6oMI6rdcjMkB2r5JPD9Y8Lk1dhTPvnOWn8Dmnp66fXg6AqR2WlJCD4Q G68w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711406346; x=1712011146; 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=DqLcZpfFx6aJ4RsnMU0gGS++kj6ptNsIBWGAoEw1/x4=; b=lLCn2jwZNJgYMs4Zg/mxrIPpckKjqGIpE8Ju8GPGpWKk5mmEE978qgbknrl4/T0ta1 HnWbAX39Ml8OfgSq0LHvGSlRdqWsfvTpJSbn75R/oK6uCCA5CiJ6RuvJ1rETcgNZ/hlG L/1S3JjAO+TnpvsGI4TC/Oy4xg/n06MdmD1izhvc5NxRMAYP3iUklUW8QmxeGAV6DETH Fh8Rq57F6ROSCkdkx1MRL6MmG+ufG7KUc5sa3Nf5mSQME6r4BywW+mShS4Pn+C3rUsmi 70IxU6rm379bU39Sp+gaxTSL1QXudKhMi8DipCiLjiKdzjIkjnID6ih68OZ4IwJBls6I oaDQ== X-Forwarded-Encrypted: i=1; AJvYcCUG80JvsQs7NTl3Slwkqfru4zbGGtwo+uS19ckTapL4zmI7SWoU8vH0GUOP7225LtTK+NqKdPUFaorrdoCAlEx94xeL6OFs1zAKOjAZAS4svEQ2Xk8= X-Gm-Message-State: AOJu0Yygs4pP1hweuqGP0tpIHkFu8f/ra1AzdNViexqjgsp0gc9muc+w U6STRhBdDm1d8hJTetIaIgqcrMckV9p9igPD869tLwwneXIlmmoO X-Google-Smtp-Source: AGHT+IH3T67VWUI4TBUfClcieBCpVxYsnEW19lJIDeWsn1YqrxvgYKauhlG9YQbW/4ViSpj7DUfkpQ== X-Received: by 2002:a25:dbcb:0:b0:dcb:dd25:74c4 with SMTP id g194-20020a25dbcb000000b00dcbdd2574c4mr1167520ybf.52.1711406346402; Mon, 25 Mar 2024 15:39:06 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id a17-20020a0cc591000000b006904d35e1c6sm3964406qvj.58.2024.03.25.15.39.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 15:39:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id F1A9E27C005B; Mon, 25 Mar 2024 18:39:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 25 Mar 2024 18:39:05 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduvdcutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhepjeeihfdtuedvgedvtddufffggeefhefgtdeivdevveelvefhkeehffdtkeeihedv necuffhomhgrihhnpehruhhsthdqlhgrnhhgrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunh drfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Mar 2024 18:39:03 -0400 (EDT) Date: Mon, 25 Mar 2024 15:38:32 -0700 From: Boqun Feng To: Kent Overstreet Cc: Linus Torvalds , 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: 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_153909_373392_1DFCCDB3 X-CRM114-Status: GOOD ( 50.50 ) 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 Mon, Mar 25, 2024 at 06:09:19PM -0400, Kent Overstreet wrote: > On Mon, Mar 25, 2024 at 02:37:14PM -0700, Boqun Feng wrote: > > On Mon, Mar 25, 2024 at 05:14:41PM -0400, Kent Overstreet wrote: > > > On Mon, Mar 25, 2024 at 12:44:34PM -0700, Linus Torvalds wrote: > > > > On Mon, 25 Mar 2024 at 11:59, Kent Overstreet wrote: > > > > > > > > > > To be fair, "volatile" dates from an era when we didn't have the haziest > > > > > understanding of what a working memory model for C would look like or > > > > > why we'd even want one. > > > > > > > > I don't disagree, but I find it very depressing that now that we *do* > > > > know about memory models etc, the C++ memory model basically doubled > > > > down on the same "object" model. > > > > > > > > > The way the kernel uses volatile in e.g. READ_ONCE() is fully in line > > > > > with modern thinking, just done with the tools available at the time. A > > > > > more modern version would be just > > > > > > > > > > __atomic_load_n(ptr, __ATOMIC_RELAXED) > > > > Note that Rust does have something similiar: > > > > https://doc.rust-lang.org/std/ptr/fn.read_volatile.html > > > > pub unsafe fn read_volatile(src: *const T) -> T > > > > (and also write_volatile()). So they made a good design putting the > > volatile on the accesses rather than the type. However, per the current > > Rust memory model these two primitives will be UB when data races happen > > :-( > > > > I mean, sure, if I use read_volatile() on an enum (whose valid values > > are only 0, 1, 2), and I get a value 3, and the compiler says "you have > > a logic bug and I refuse to compile the program correctly", I'm OK. But > > if I use read_volatile() to read something like a u32, and I know it's > > racy so my program actually handle that, I don't know any sane compiler > > would miss-compile, so I don't know why that has to be a UB. > > Well, if T is too big to read/write atomically then you'll get torn > reads, including potentially a bit representation that is not a valid T. > > Which is why the normal read_volatile<> or Volatile<> should disallow > that. > Well, why a racy read_volatile<> is UB on a T who is valid for all bit representations is what I was complaining about ;-) > > > where T is any type that fits in a machine word, and the only operations > > > it supports are get(), set(), xchg() and cmpxchG(). > > > > > > You DO NOT want it to be possible to transparantly use Volatile in > > > place of a regular T - in exactly the same way as an atomic_t can't be > > > used in place of a regular integer. > > > > Yes, this is useful. But no it's not that useful, how could you use that > > to read another CPU's stack during some debug functions in a way you > > know it's racy? > > That's a pretty difficult thing to do, because you don't know the > _layout_ of the other CPU's stack, and even if you do it's going to be > changing underneath you without locking. > It's a debug function, I don't care whether the data is accurate, I just want to get much information as possible. This kinda of usage, along with cases where the alorigthms are racy themselves are the primary reasons of volatile _accesses_ instead of volatile _types_. For example, you want to read ahead of a counter protected by a lock: if (unlikely(READ_ONCE(cnt))) { spin_lock(lock); int c = cnt; // update of the cnt is protected by a lock. ... } because you want to skip the case where cnt == 0 in a hotpath, and you know someone is going to check this again in some slowpath, so inaccurate data doesn't matter. > So the races thare are equivalent to a bad mem::transmute(), and that is > very much UB. > > For a more typical usage of volatile, consider a ringbuffer with one > thread producing and another thread consuming. Then you've got head and > tail pointers, each written by one thread and read by another. > > You don't need any locking, just memory barriers and > READ_ONCE()/WRITE_ONCE() to update the head and tail pointers. If you > were writing this in Rust today the easy way would be an atomic integer, > but that's not really correct - you're not doing atomic operations > (locked arithmetic), just volatile reads and writes. > Confused, I don't see how Volatile is better than just atomic in this case, since atomc_load() and atomic_store() are also not locked in any memory model if lockless implementation is available. > Volatile would be Send and Sync, just like atomic integers. You don't > need locking if you're just working with single values that are small > enough for the machine to read/write atomically. So to me Volatile can help in the cases where we know some memory is "external", for example a MMIO address, or ringbuffer between guests and hypervisor. But it doesn't really fix the missing functionality here: allow generating a plain "mov" instruction on x86 for example on _any valid memory_, and programmers can take care of the result. Regards, Boqun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel