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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 888FBC19F2E for ; Thu, 27 Feb 2025 16:55:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0ED1610EB3D; Thu, 27 Feb 2025 16:55:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="hetNUXYK"; dkim-atps=neutral Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by gabe.freedesktop.org (Postfix) with ESMTPS id 56F9C10EB3D; Thu, 27 Feb 2025 16:55:13 +0000 (UTC) Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6e66d4f3be2so16034296d6.3; Thu, 27 Feb 2025 08:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740675312; x=1741280112; darn=lists.freedesktop.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=980w1YB2itkCLikkG2aaoTrs25//o08fnkucvOSS5Ig=; b=hetNUXYKezpoNz8Ip1TH1c9I0hNuP/Gkuia0fZFFdOUP67Ce8NoXLUTSt8e51dIa/Z waIqgptQzJhHuOu2OIB7Wk0eUSa8DwWM1S0QgCMtezmsNgK1hOYeaM/5x3pmrZ19G2xV wwLdog7bwFhff5fXWdSOVptWt2WcuMAWf0Vdprkov0Pw9amWMvIyxHmqWrL/QxDE4hyK VnJoJu/NMUVMd0CZZthNvv1PtEfmt02/kOIQe4jgyzz5iP2PLOFXjdo4oG5ADP6Y53TX ycXaubGkfkIjad0RxetB7Jp/AQ9v0ZtA3N5KSGFQTI54yUCsF0BkSOBE2IA+6PQI4NOq Ulrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740675312; x=1741280112; 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=980w1YB2itkCLikkG2aaoTrs25//o08fnkucvOSS5Ig=; b=dNfZfOxrxo/Z3O6QxXZJw484s877Cac2AXMkI5ugIeEJRO+cx2TNZ5z2wW7Q9KklTh 91aHp2DDVejt4WuqsiD7qhAbFa9mgHR3QdGTQK7aPKS6Mru5GqaY9MXCqpiACpc5ovud 1mLZlddf3+uMbWD9yS6qRcNjjSJTtqQsUFerCEYT7PktwuFSNDa47ZYqUJ2Y2s0xBQwP 1W235ve40ENGHs4DXmPzlzyg3nYaz0nyEuybgP5IylGanFW3Bf7RgTaN7TJeEqVhfFBh lmFmx7+WxfhAQ+AF/wTe56AQDiWafse6T5DsDW0ZDC/NsL24ezgmSPPaCYVYVcHXkHZt wXFA== X-Forwarded-Encrypted: i=1; AJvYcCWbBI/DY/fJ1Nyx544g5NVIJ6lgQlwEHVHBP6yDcc8Ixn9JEqkn3+ehmcDMflD/eMl2jFnkY/fk3Q==@lists.freedesktop.org, AJvYcCXqy0q6UIjMLEXgo4LSiW5PzM8NjZ+B9CXzsTyWehuRrqgODvuSAdy647AxQFE+AXW9V6EEBKZZzc0=@lists.freedesktop.org X-Gm-Message-State: AOJu0YzqDrNiydbZs8AZuGB0AwWmNBZSiMNUuw5l8x06QK8wfHwuaB9a jV8/ZnzkwUbBi3vIRp8Zo7qrkHUlDCO7XIPWLO4bQ2KKBuZJV4xW X-Gm-Gg: ASbGnctgr0Eg6R3Q7jeOOvvcCy+tVFMENz3GBzI3ZltGN2H0ABcG7so2kfLa3XTPNi8 78M2ym/NfnpmYK8q3fSH8ChY/NS9xLmygSao/AY2hCBwsxgZaT60SwzRVg+ppd0GbdGai+Jy+mf Defm4DjpTMgmtkVPhDDZz5VXW/6pMg/K9Vl9z2lw5ejDA9dQQf4apodjQ6Dh+JIlgYm8jvcPzuK NlIvNS4F07fkzG0C2QqpIh/l416wM9HalmDZa7243Jzci2UuRAiR0t0Yz/yrG+ksChaAEOZh8WY GSCOFFjYenPI1kPtiXJhLk2ExIgCodHTWRWq1PzU6Hz5UQIt7IyWqntjRO5IvmfQ/lxVfTb3Zc1 S8piXkls2Pe7mlYhp X-Google-Smtp-Source: AGHT+IFZH/bq4PBfo5JkoQRcCnek7eycxVwpDI/O4N5aADIrrRHM4Y9CBi8g17hXzU4f1wl6FDEpXw== X-Received: by 2002:a05:6214:21cf:b0:6d8:9960:b063 with SMTP id 6a1803df08f44-6e8a0cbf934mr2932786d6.14.1740675312516; Thu, 27 Feb 2025 08:55:12 -0800 (PST) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e8976ccaefsm11596906d6.74.2025.02.27.08.55.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 08:55:12 -0800 (PST) Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 835DA1200043; Thu, 27 Feb 2025 11:55:11 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Thu, 27 Feb 2025 11:55:11 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdekkedttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddv necuhfhrohhmpeeuohhquhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilh drtghomheqnecuggftrfgrthhtvghrnhephedugfduffffteeutddvheeuveelvdfhleel ieevtdeguefhgeeuveeiudffiedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepgh hmrghilhdrtghomhesfhhigihmvgdrnhgrmhgvpdhnsggprhgtphhtthhopeduhedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhgghesnhhvihguihgrrdgtohhmpdhrtg hpthhtohepuggrkhhrsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehjohgvlhgrghhn vghlfhesnhhvihguihgrrdgtohhmpdhrtghpthhtoheprggtohhurhgsohhtsehnvhhiug hirgdrtghomhdprhgtphhtthhopegrihhrlhhivggusehgmhgrihhlrdgtohhmpdhrtghp thhtohepghgrrhihsehgrghrhihguhhordhnvghtpdhrtghpthhtohepjhhovghlsehjoh gvlhhfvghrnhgrnhguvghsrdhorhhgpdhrtghpthhtohepjhhhuhgssggrrhgusehnvhhi ughirgdrtghomhdprhgtphhtthhopegsshhkvghgghhssehnvhhiughirgdrtghomh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Feb 2025 11:55:10 -0500 (EST) Date: Thu, 27 Feb 2025 08:55:09 -0800 From: Boqun Feng To: Jason Gunthorpe Cc: Danilo Krummrich , Joel Fernandes , Alexandre Courbot , Dave Airlie , Gary Guo , Joel Fernandes , John Hubbard , Ben Skeggs , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, paulmck@kernel.org Subject: Re: [RFC PATCH 0/3] gpu: nova-core: add basic timer subdevice implementation Message-ID: References: <20250226004916.GB4959@nvidia.com> <20250226172120.GD28425@nvidia.com> <20250226234730.GC39591@nvidia.com> <20250227144618.GE39591@nvidia.com> <20250227161733.GH39591@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250227161733.GH39591@nvidia.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote: > On Thu, Feb 27, 2025 at 07:18:02AM -0800, Boqun Feng wrote: > > On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote: > > > On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote: > > > > And if you don't store the HrTimerHandle anywhere, like you drop() it > > > > right after start a hrtimer, it will immediately stop the timer. Does > > > > this make sense? > > > > > > Oh, I understand that, but it is not sufficient in the kernel. > > > > > > You are making an implicit argument that something external to the > > > rust universe will hold the module alive until all rust destructors > > > are run. That is trivialy obvious in your example above. > > > > > > > The question in your previous email is about function pointer of hrtimer > > EAF because of module unload, are you moving to a broader topic > > here? > > No > > > If no, the for module unload, the argument is not implicit because in > > rust/macro/module.rs the module __exit() function is generated by Rust, > > and in that function, `assume_init_drop()` will call these > > destructors. > > That is not what I mean. You can be running code in multiple threads > from multiple functions in the module those are all being protected > implicitly by external C code functions. Rust itself is not managing > module life time. > > Then you are making the argument that everything created by a rust > module somehow traces its reference back to the module itself, > regardless of what thread, callback or memory was used to create it. > > So all bindings for everything are expected to clean themselves up, > recursively. > Right, that would be the most cases in Rust if you want to control the cleanup orderings. > That does make sense, but then it still raises questions that things > like workqueue don't seem to have the cleanup. > It was because the existing Workqueue was designed for built-in cases, and we should fix that. Thank you for spotting that. > I still wonder why you couldn't also have these reliable reference > counts rooted on the device driver instead of only on the module. > You could put reliable reference counts anywhere you want, as long as it reflects the resource dependencies. Regards, Boqun > Jason