I am putting this code up for discussion of the actual problem.
I am not sure what all consumes idr at the moment but it seems to
reach all the way into ports based on 613723bac219c.
With Linux code idr operations can go like (seen with mt7925):
[80.365036] idr_init: idr 0xfffff800017415b8
[80.367429] idr_init: idr 0xfffff800017415b8
[80.403823] idr_init: idr 0xfffff800017415b8
init called 3 times (3x mtx_init)
...
... normal access operation
...
[100.005887] idr_destroy: idr 0xfffff800017415b8
destroy called, (mtx_destroy)
[100.006539] idr_remove_all: idr 0xfffff800017415b8
[100.007213] idr_remove: idr 0xfffff800017415b8
[100.007812] idr_remove:310: idr 0xfffff800017415b8
[100.008468] idr_get_next: idr 0xfffff800017415b8
[100.009087] idr_get_next:400: idr 0xfffff800017415b8
[100.009778] idr_is_empty: idr 0xfffff800017415b8
[100.010402] idr_for_each: idr 0xfffff800017415b8
more access to the idr (which would require the mtx)
[100.011012] idr_destroy: idr 0xfffff800017415b8
and another destroy
This obviously does not work with a destroyed mutex on FreeBSD and the
above trace was done without locking. Adding a destroyed mutex check
(as inidicated in the patch) is not really a solution I would want to
live with either apart from as a temporary stop-gap.
On Linux idr seems to be based on radix which seems to be based on
xarray and the callers seem to be responsible to make sure that
consistency can be guaranteed.
The caveat with this is that our implementation(s) would have to be
RCU-safe, which I belive may be harder to accomplish.
Sponsored by: The FreeBSD Foundation