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 127D8C54E58 for ; Mon, 25 Mar 2024 21:38:09 +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=m2DS4JaDUpW3kyuB/8fy+1z/PN/rDpIO0BEIYYCou44=; b=GrOFR92CRAwg/X wnpNV3be1Hl/guyJ+PhlLfO86pb2gryWSmIer0o0GtCzMAqWw/egWnTo/bTfvd8GVtuLRa4yccp9Y 8q0U3EIgksS+l53djWV638090lnJD0Ez/xVvgAeVyFz31sCHJpLJ+osWVhtT9/tU0uW+ra5b11ZU9 RKIK49M1fTip0WlvHVn0l6CIWo/h75t5//IdkTrFWn2u53gMmHymADn/XK/EJAXhGVnOgBKCH4x/p A/TCU1rv2iCGqFcJrm5ljKpHZhFE5s6mr2E96y/xyY2e2GJfE2OlLKSRpw25wdx+Ypp69Rly7GV+m iSHQNcRXSG11NnpiRggg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ros0x-000000023gW-2t5r; Mon, 25 Mar 2024 21:37:55 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ros0t-000000023ed-0VPQ for linux-arm-kernel@lists.infradead.org; Mon, 25 Mar 2024 21:37:53 +0000 Received: by mail-qk1-x732.google.com with SMTP id af79cd13be357-789e3f17a6eso347622685a.0 for ; Mon, 25 Mar 2024 14:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711402669; x=1712007469; 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=DXvJB4PTr9BnmGHzkolraHMPsM/PHcpz2o1jxgX00Cw=; b=P4jjPAHfWl6DknnihqxJAnyl4pSwnyk3T+Q93m74TJ6shXxyeTlmiHJfK1Zj6z5dYv D+BOvHtz4tvYpOTYwvjiMiAyAolDxCoUmvkt6qSbZ0n4Gj8jmXm9C3drxeMHaYKeApBG 8scz9/ifGOVx632bhbVPzVxZEbqcpS6TXXux0mXQK/BfBW4R5/CP9WL1z6M5Vf8oen7p 5HI6FmWyW3bvJjvwIkbBtr0KMCVempV69L3MPQ9XXHYeZXjIpxyeVH0Tqhhj5sDHHdJx 8hRlbnYSzX6e8ZZnkryT3ZK++oFFU6lCnSrY2NlpjGZfMvaI+k1mPLSQscS3u4tlxd8k kFvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711402669; x=1712007469; 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=DXvJB4PTr9BnmGHzkolraHMPsM/PHcpz2o1jxgX00Cw=; b=F8dJXx/kMtXqSdGcf8QdyqiiCwQDtvOGeA74EPSt03CHKquMm/J+ijc8pxTJRnAzsx /ODFigWQk6sD9/jQerFyfc1sgFWBxuIyXvkUHTitHuVEg/F01wIoRynRlWsvKZoxNvpi gsRils2JHgalBscuoHgYuU7tAHR7GRXU0eqEYaJlRJmqUK++QKuhFW1cX+KqAEg39ezl pAikBMlDbq3Ho4EtFlcIiFRO8XjJRAusho+vqaRLncJt9etE85h/yJtTQ65DCnljQxzL VrMVj9gLaDrxa6XZYkk6p9Wd37emz4vajjHTzWffpmNHV2DPmejKwSiFB0XYLQMxC46W 1Eeg== X-Forwarded-Encrypted: i=1; AJvYcCVrbC6X8VYII4oW2kL9isLxIss5xM01ouTscpABCotWi9eyMtiYPp5pAaBUsjQpRK1KPw4JFStrcNbedbc/r0kPyvMj9d/QSvrjtS0HPi0PbFEQLnQ= X-Gm-Message-State: AOJu0Yw6SXs3p4RIOwa2VOCwsm2URcjEW3+514lIoKOJXgQa6pwz425N sjJz4XMGwYvm3ZiS1QMpdGHOf138ZM3q1zgen7nTidGb47i1SEu0 X-Google-Smtp-Source: AGHT+IEcUMc58g6IuQ5hGxe8QG2RU/su4immaoKU7ZFPkQningk7dx0ah1v7u/eFIaHFnL28zDZMRA== X-Received: by 2002:a05:620a:2211:b0:78a:5c11:e7ac with SMTP id m17-20020a05620a221100b0078a5c11e7acmr2588111qkh.40.1711402669111; Mon, 25 Mar 2024 14:37:49 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id v25-20020ae9e319000000b0078838c7acbfsm2467972qkf.42.2024.03.25.14.37.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 14:37:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id 43A091200032; Mon, 25 Mar 2024 17:37:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 25 Mar 2024 17:37:47 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduuddgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeejiefhtdeuvdegvddtudffgfegfeehgfdtiedvveevleevhfekhefftdek ieehvdenucffohhmrghinheprhhushhtqdhlrghnghdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsoh hquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Mar 2024 17:37:45 -0400 (EDT) Date: Mon, 25 Mar 2024 14:37:14 -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: <20240322233838.868874-1-boqun.feng@gmail.com> 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_143751_866042_00FBB50A X-CRM114-Status: GOOD ( 38.10 ) 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 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. > > > > Yes. Again, that's the *right* model in many ways, where you mark the > > *access*, not the variable. You make it completely and utterly clear > > that this is a very explicit access to memory. > > > > But that's not what C++ actually did. They went down the same old > > "volatile object" road, and instead of marking the access, they mark > > the object, and the way you do the above is > > > > std::atomic_int value; > > > > and then you just access 'value' and magic happens. > > > > EXACTLY the same way that > > > > volatile int value; > > > > works, in other words. With exactly the same downsides. > > Yeah that's crap. Unfortunate too, because this does need to be a type > system thing and we have all the tools to do it correctly now. > > What we need is for loads and stores to be explict, and that absolutely > can and should be a type system thing. > > In Rust terminology, what we want is > > Volatile > > 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? Regards, Boqun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel