Answering the one question that is about this patch rather than about the state it leaves behind, and confirming the rest.
> Because rocket_remove() doesn't clear the dev pointer or compact the > array, wouldn't subsequent out-of-order unbinds match stale pointers > since find_core_for_dev() now searches up to max_cores? There are three callers: rocket_remove() and the two runtime PM callbacks. The driver core calls remove once per device, and the PM callbacks cannot run for an unbound one, because rocket_core_fini() has already called pm_runtime_disable() on it. The slots the widened search adds are either never filled, where .dev is NULL and matches nothing, or held by a device that has been unbound - and nothing asks after such a device again. What the narrower search did do was lose live cores. Unbind the core in slot 0 of three: num_cores drops to two, so find_core_for_dev() stops before slot 2. The core sitting there is still bound and still running, but its own runtime suspend and resume callbacks start returning -ENODEV. Searching every allocated slot fixes that as well. An earlier version of this patch did clear .dev on removal and take a free slot on probe. I dropped both. Clearing .dev turns rocket_open()'s unconditional cores[0] into a NULL dereference whenever the core in slot 0 is unbound while its siblings stay bound, which is a worse failure than the one it cures - and it is the same rocket_open() issue listed further down. That is why the commit message says out-of-order unbind wants more thought than a fix should carry, rather than quietly half-fixing it. On the rest: all eight are pre-existing and I agree with all eight. Two of them have names already. The ERR_PTR left in the file-scoped rdev is fixed by Guangshuo Li's "accel/rocket: clear rdev on device init failure", posted in July and still unapplied: https://lore.kernel.org/dri-devel/[email protected]/ It carries my Reviewed-by. It would be good to see that one land. The devm point may explain something I measured this week and could not account for. Unbinding and rebinding all three cores walks the DRM minor upwards - 1 through 10 over ten rounds in one run - and only a module reload puts it back to 0. I have not shown that the allocations are leaked, only that something survives a rebind that should not, which is consistent with what you describe. Igor
