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
