From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (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 2CC9F168 for ; Wed, 7 Jul 2021 15:44:46 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 9AC0B2B00980; Wed, 7 Jul 2021 11:44:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Jul 2021 11:44:45 -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=zHnMP2z+r/Nzd12JU8FofgpOL7L /E4Zm49J/UP+WdJ4=; b=KxDxmLPaUGqn1WiGoCDIRa2c/IyxLBrfPi4a8HH+Ory Nx+Qz+FVrWlX8TH55CO9CiC0DpyDjhNKW3MO/CtXtndpblGaMdELNPeI6UpX4azw E9yu1bHMa11WTnghbdz2drynYJhQ66RHxZjAPTGfdLNejWJblVFdBziSiAxgLvXn ALd6UCzwROa+8Mmy3OW20yW5kOQmQEzwlujmPM2DgB4q5H8XKlos/+CvTPksL9fi OG0nxfmmdHDe8ts8BNPfALfYiCRLyziadhsM2JTVttgdE8R4NmMzv9GZLY2/kOpp RQObkRJh2440zYVUeGM6ltIaaaQ1xsitsPWUg+Vod5A== 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=zHnMP2 z+r/Nzd12JU8FofgpOL7L/E4Zm49J/UP+WdJ4=; b=cxcyDehcMczMKZEF0N/5wj bsJ2dkINdJ6FSLsnvEYXT5sjvW9js6LShN8ZuSchu004Lh0TXzdB3V+2uKO9Le/L ISWrlLOZY07r8zCK5IVRuYAGZbKgb/tXHKYBQlKWyDB8ajduquO9ktVLT2M86Z1a 3B6aKC0ptcf4ItSQki378uwLEKjn0HLcgX7ivLP5U1iwT4Yq6MGevooGvw1P+Qo9 DlCR+FsfWVU5X+ybFL+JOXQGokYpp6XY8eQ03Y39Emcnt/EyJhD5dyXNMPbu8Rfd N01seM0ChzgL8J5MdrqBB+4YdycbR95PJ1c4BdMm6rbBEyfChALOlnVOixGsDw8A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddvgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghgucfm jfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepkeehgedtge dtudeuleekgefffefglefguefhgfffgeefudekfeffgfehiedvfeetnecuffhomhgrihhn pehgihhthhhusgdrtghomhdprghrtgdrrhhspdhpthhrrdgrshenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhhdrtgho mh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jul 2021 11:44:42 -0400 (EDT) Date: Wed, 7 Jul 2021 17:44:41 +0200 From: Greg KH To: Miguel Ojeda Cc: James Bottomley , Julia Lawall , Laurent Pinchart , Linus Walleij , Roland Dreier , ksummit@lists.linux.dev Subject: Re: [TECH TOPIC] Rust for Linux Message-ID: References: <20ad13eb229b15fd14d870832d43a1605ba5c24a.camel@HansenPartnership.com> <1f2a62c19845e4602817c2130d47bbea02d04d1d.camel@HansenPartnership.com> 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 Wed, Jul 07, 2021 at 05:15:01PM +0200, Miguel Ojeda wrote: > For instance, we have a `Ref` type that is similar to `Arc` but reuses > the `refcount_t` from C and introduces saturation instead of aborting > [3] > > [3] https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/sync/arc.rs This is interesting code in that I think you are missing the part where you still need a lock on the object to prevent one thread from grabbing a reference while another one is dropping the last reference. Or am I missing something? The code here: fn drop(&mut self) { // SAFETY: By the type invariant, there is necessarily a reference to the object. We cannot // touch `refcount` after it's decremented to a non-zero value because another thread/CPU // may concurrently decrement it to zero and free it. It is ok to have a raw pointer to // freed/invalid memory as long as it is never dereferenced. let refcount = unsafe { self.ptr.as_ref() }.refcount.get(); // INVARIANT: If the refcount reaches zero, there are no other instances of `Ref`, and // this instance is being dropped, so the broken invariant is not observable. // SAFETY: Also by the type invariant, we are allowed to decrement the refcount. let is_zero = unsafe { rust_helper_refcount_dec_and_test(refcount) }; if is_zero { // The count reached zero, we must free the memory. // // SAFETY: The pointer was initialised from the result of `Box::leak`. unsafe { Box::from_raw(self.ptr.as_ptr()) }; } } Has a lot of interesting comments, and maybe just because I know nothing about Rust, but why on the first line of the comment is there always guaranteed a reference to the object at this point in time? And yes it's ok to have a pointer to memory that is not dereferenced, but is that what is happening here? I feel you are trying to duplicate the logic of a "struct kref" here, and that requires a lock to work properly. Where is the lock here? thanks, greg k-h