Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp45904pxb; Thu, 15 Apr 2021 22:19:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJlUB5Ydn1he1ECLiJ8khxcEZ/fUnzTH0cvMC5eWRO1N30wKkxOJT6WR2KdTANoWLFG41P X-Received: by 2002:a17:906:c79a:: with SMTP id cw26mr6646956ejb.220.1618550398502; Thu, 15 Apr 2021 22:19:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618550398; cv=none; d=google.com; s=arc-20160816; b=PBKQwkRKUEyyAV/GL/V9gcXzWQUaL4/4mW6bOv+sUWbquohIX755k3SPKg9fNK79ll WSmRbgHWGGjntd5bmYUVOZPPArOSVp8SAXjpyjGv+Np5XPnsgPLNdNORb+l6zgb/FDJy tXnuDY1zWosyhScZGSBpHD85/KPsYdbkH8Z1d2+0Qaj/l8svSLSeIrMNqCbcA1JLm1qi LgAFdqV8xSS2w0y+rLIYRTYPVpgsndYpKtal7BOCQ/XrkoaxCTgAnazXb3muY/BXV7xd iNaIoEQpqAeTUxemhvilLnm3LG2CTa4ElDVXLdzA0AWac2305AElf7u0xozHqEgq4/C4 TICg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=h/j3EPtsk6sFPLhViDwCVPqvIn6HguFgWYAaIE2CjVA=; b=Lb3EQzjM6yU9P2Qp+fTyRDlDZyY2tK3i+NlQLP9L1kTP9xgV5qOnOv5CEnSN4T+CUA TECTFdRGALzAXxlKgQuA4aEWe1mYGgyUNNUkaggLgB/nIt0D0NJWNvMiWDyDhgpjR2qA V254H8TcI30XtTXUhocRPUp5JkGkJJx6Iecm04/lcrIXjsMvfiJe2R4cDpOUVUgJXnwa RtcCgZV8+fHjfkKWLr05APoF8s/fQMuoC3cl/F3+YGsQ8O/kv0kgikVCXhmPtRHOn1TF +HkkdhvyhMA9biMGWV+CSeTK1Xj+HNxwn8+4sxLsqNcZuvv5J103zYedHIUr7SVbljF9 OWWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qiRj45Id; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f7si1286722edd.239.2021.04.15.22.19.35; Thu, 15 Apr 2021 22:19:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qiRj45Id; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237961AbhDPE2O (ORCPT + 99 others); Fri, 16 Apr 2021 00:28:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234757AbhDPE2O (ORCPT ); Fri, 16 Apr 2021 00:28:14 -0400 Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7F10C061574; Thu, 15 Apr 2021 21:27:48 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id o2so6555068qtr.4; Thu, 15 Apr 2021 21:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=h/j3EPtsk6sFPLhViDwCVPqvIn6HguFgWYAaIE2CjVA=; b=qiRj45IdAFMPjAJ5IZe4MNJGSxzIlodMYVOaCCmfT0g0sEbUTVwBmtNahpfdutLtkz XoOhagfcKGJpGD5WC1TKxQpk+klt29nJg/UXK630gWCX/cOLD+qYWGuYR4iq6zKmRmzK HmJDzy0X49IobhbfEarMqZs93zxei+a0Jh2osfEoh9ZfJPXiJJT9xqtD2dvCDK0iyAhv lbFhiImjFv8jxDn3Un/uWlAInOd8F29SmMfVSeZC28CdCpByXd8mFZHLrTJSyozRWJAt yjwi5lBa/419P/5qs+PjbVWRBbFLZIIvHFr9Z1pp5RPq1FfuMcqOm3fBg4BvvWExy7dg DX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h/j3EPtsk6sFPLhViDwCVPqvIn6HguFgWYAaIE2CjVA=; b=V2Lg8C6ykrOkBL2J5wcnkBB5jBsjtBxZ3R6YsKBWIcXOgR6O77KV+FGaop6geZtyx/ Pqgo5qyRPs0HczGM51MN/DlmUFS4MS4NFOsudQAomNsicKnhD0D0TY/EqB0+nZ6XD7V9 HFZzUiq6QUYKywpDGDvWyMiKpUSZeECmsfpi0kzFBPyc1FCGGxfguje4amOzfEcl1u8X o7ZsfcybsPcPnJV9vEnpxT915tgp2rivXDIoiCWKVeWYIcq89lyksppD+zvS4jL6MzoF +gr0n6pmRdgSmwTDvg2RYekhISpmhQSxhgj6O8p3lyq1UlI69SCdIwlyOmcy5kROcQ8V jA9A== X-Gm-Message-State: AOAM531EQBtazemJz/9bF9TrAK4qR6YJJdvi2Mat2grD+ham+aMlrdrq BehNm2laduUHBq1PgtYDBO4= X-Received: by 2002:ac8:7c56:: with SMTP id o22mr6253242qtv.133.1618547267947; Thu, 15 Apr 2021 21:27:47 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id t198sm3464119qke.44.2021.04.15.21.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Apr 2021 21:27:47 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 6775127C0054; Fri, 16 Apr 2021 00:27:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 16 Apr 2021 00:27:46 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelgedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhn ucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrth htvghrnhephffgledvjeehkedtgeehudehhfegfeetgeelffffuefgueevtdelfeelgeeh geeknecuffhomhgrihhnpehruhhsthdqlhgrnhhgrdhorhhgpdhkvghrnhgvlhdrohhrgh dpghhithhhuhgsrdgtohhmnecukfhppedufedurddutdejrddugeejrdduvdeinecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomh gvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeeh heehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmh gv X-ME-Proxy: Received: from localhost (unknown [131.107.147.126]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CBB5108005C; Fri, 16 Apr 2021 00:27:43 -0400 (EDT) Date: Fri, 16 Apr 2021 12:27:39 +0800 From: Boqun Feng To: Peter Zijlstra Cc: ojeda@kernel.org, Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Josh Triplett , Nick Desaulniers , Wedson Almeida Filho Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: References: <20210414184604.23473-1-ojeda@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Copy LKMM people, Josh, Nick and Wedson] On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote: > On Wed, Apr 14, 2021 at 08:45:51PM +0200, ojeda@kernel.org wrote: > > > Rust is a systems programming language that brings several key > > advantages over C in the context of the Linux kernel: > > > > - No undefined behavior in the safe subset (when unsafe code is > > sound), including memory safety and the absence of data races. > > And yet I see not a single mention of the Rust Memory Model and how it > aligns (or not) with the LKMM. The C11 memory model for example is a > really poor fit for LKMM. > I think Rust currently uses C11 memory model as per: https://doc.rust-lang.org/nomicon/atomics.html , also I guess another reason that they pick C11 memory model is because LLVM has the support by default. But I think the Rust Community still wants to have a good memory model, and they are open to any kind of suggestion and input. I think we (LKMM people) should really get involved, because the recent discussion on RISC-V's atomics shows that if we didn't people might get a "broken" design because they thought C11 memory model is good enough: https://lore.kernel.org/lkml/YGyZPCxJYGOvqYZQ@boqun-archlinux/ And the benefits are mutual: a) Linux Kernel Memory Model (LKMM) is defined by combining the requirements of developers and the behavior of hardwares, it's pratical and can be a very good input for memory model designing in Rust; b) Once Rust has a better memory model, the compiler technologies whatever Rust compilers use to suppor the memory model can be adopted to C compilers and we can get that part for free. At least I personally is very intereted to help Rust on a complete and pratical memory model ;-) Josh, I think it's good if we can connect to the people working on Rust memoryg model, I think the right person is Ralf Jung and the right place is https://github.com/rust-lang/unsafe-code-guidelines, but you cerntainly know better than me ;-) Or maybe we can use Rust-for-Linux or linux-toolchains list to discuss. [...] > > - Boqun Feng is working hard on the different options for > > threading abstractions and has reviewed most of the `sync` PRs. > > Boqun, I know you're familiar with LKMM, can you please talk about how > Rust does things and how it interacts? As Wedson said in the other email, currently there is no code requiring synchronization between C side and Rust side, so we are currently fine. But in the longer term, we need to teach Rust memory model about the "design patterns" used in Linux kernel for parallel programming. What I have been doing so far is reviewing patches which have memory orderings in Rust-for-Linux project, try to make sure we don't include memory ordering bugs for the beginning. Regards, Boqun