Jason Gunthorpe wrote: > On Thu, Jan 29, 2026 at 03:08:22AM +0200, Laurent Pinchart wrote: > > > The latter already have robust schemes to help the driver shutdown and > > > end the concurrent operations. ie cancel_work_sync(), > > > del_timer_sync(), free_irq(), and *notifier_unregister(). > > > > One a side note, devm_request_irq() is another of the devm_* helpers > > that cause race conditions, as interrupt handlers can run right after > > .remove() returns, which drivers will most likely not handle correctly. > > Yes! You *cannot* intermix devm and non-devm approaches without > creating very subtle bugs exactly like this. If your subsystem does > not provide a "devm register" helper its drivers shouldn't use devm.
I wonder if we should have a proactive debug mode that checks for idiomatic devres usage and flags: - registering devres actions while the driver is detached - registering devres actions for a device with a driver that has a .remove() method - passing a devres allocation to a kobject API - invoking devres release actions from a kobject release API
