From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47EEA70 for ; Thu, 8 Jul 2021 18:01:58 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 247B758034B; Thu, 8 Jul 2021 14:01:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 08 Jul 2021 14:01:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=tQsnC8f4RCma0d34nYIoAZ3m3VM Al6Zmw1kpuLuKwAc=; b=GTIpRgFbWPSp12QsE929C8cIOWdRQ2S8bXOoVCiGBwy tDwPMq7k3zwM4FuA+nfMu6D3SRgwqjHdTaQIinyJRQRk33VFQmBIyIJmgpue0rpU 1uvvu3oEsBobk9enU1K6YWU5L2OoCoFnf/KXC/pEz2rhfSzRZD7tI4uS7WDRBBIn UHZvwL/5DwwLRGih2NhrlQhCHwfOhhxSff05pO6LZUXquJWWK91qG8XauBifCV0T oiaagWDL71Z9VrCOHVt5RdaVA+bBiZQ2ilWToXhYBpQ9o7w2KCtWtaxq51F3HXAx 32vfNMZFQoM/1gQXO4eZHUal/WV8JAiWDM7ENTkJSdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tQsnC8 f4RCma0d34nYIoAZ3m3VMAl6Zmw1kpuLuKwAc=; b=bXCdXcAAapj8e5ucHymtVK oeQqxxvYV556FLQfHxhOptwMXr/DJ3hU9Afs2xEXA637/DTfNPuAvHlHqLyRaoq5 AfqWiSuJoxy8Vi9va3fwzoIVKJJkYa5wFdr3qI36jc833p7i20iu55FWk2HtCg06 zn6/gwyMjJyahO7bQxDcgD9iX83RzNzftkSS0l2VgQ03/jo/KbqOz8TDBtt1nF2j 7+P2hCKuYoOZnrpmF503UzYMS/yin9Vc6LDaijqTnO7rTQD8KRXmctzyKVhfmXD3 6UCn0n8/YOle74e85gNYl55N4R+KmGRhf1Bmroy8O/X9tpAgFeyniobqTQECp/nw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdeggdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeevueehje fgfffgiedvudekvdektdelleelgefhleejieeugeegveeuuddukedvteenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhh drtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Jul 2021 14:01:55 -0400 (EDT) Date: Thu, 8 Jul 2021 20:01:53 +0200 From: Greg KH To: Andy Lutomirski Cc: Miguel Ojeda , Wedson Almeida Filho , Jan Kara , James Bottomley , Julia Lawall , Laurent Pinchart , Linus Walleij , Roland Dreier , ksummit@lists.linux.dev Subject: Re: [TECH TOPIC] Rust for Linux Message-ID: References: <20210707203827.GI18396@quack2.suse.cz> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jul 08, 2021 at 09:38:01AM -0700, Andy Lutomirski wrote: > On Thu, Jul 8, 2021 at 7:58 AM Greg KH wrote: > > > > On Thu, Jul 08, 2021 at 03:55:31PM +0200, Miguel Ojeda wrote: > > > On Thu, Jul 8, 2021 at 8:11 AM Greg KH wrote: > > > > > > > > Thanks for the detailed explainations, it seems rust can "get away" with > > > > some things with regards to reference counts that the kernel can not. > > > > Userspace has it easy, but note that now that rust is not in userspace, > > > > dealing with multiple cpus/threads is going to be interesting for the > > > > language. > > > > > > Regarding parallelism, userspace deals with the same problems, so I do > > > not see fundamental issues coming up there. The language was designed > > > with parallelism in mind and is a definite improvement over both C and > > > C++ in that regard. > > > > Ok, great, then how would you handle the kref issue where you need an > > external lock to properly handle the reference counting logic in Rust? > > Why is C so "bad" here that we require a lock but Rust would not? > > Can you point at a specific example in the kernel tree? Easy ones to see are any callers of kref_put_mutex() and kref_put_lock(). There's also the klist.h usage that removes the need for using those calls as there is a different lock involved, and other "bigger" locks that the driver core holds when dealing with kobjects so it "knows" it can just call kref_put(). > The > lock-and-then-put model is, at the very least, unusual, and the kref > docs talk about it like it's common and self-explanatory as to when > it's needed. I have personally never encountered a need for this, and > I'd like to know exactly what type of use case you're thinking of. Look at the above examples for details, I can't remember them all at the moment. Last time I looked into it, it took me and two graduate students with a whiteboard an hour to verify if we needed the lock or not. I was wrong and it turns out we did :) It mostly is needed when you need to return a pointer to a reference counted object from some sort of lookup as it was stored in a list or something. Which for kernel objects, is quite common. thanks, greg k-h