intrng: isrc_free_irq() don't fail if absent from table

[ehem_freebsd_m5p.com]

Summary

The table entry having been replaced shouldn't fail the teardown, but
simply not invalidate the entry.

[markj]

When does it arise that the source isn't in the table?

[ehem_freebsd_m5p.com]

I haven't observed this actually occurring, just noting if this was to occur it shouldn't be an error. Based on looking, I wonder whether this should simply be folded into intr_isrc_deregister().

Upon looking the 5 references to intr_isrc_deregister() all mark it "XXX". This is likely due to isrc_release_counters() simply being a panic since no method of releasing the counters/counter names was ever implemented. The cause appears to be the interface required for intrcnt and intrnames variables makes it difficult to reasonably mark counters as unused.

In turn the only place which now actually appears to require the intrcnt/intrnames interface is the watchdog_fire() function in sys/kern/kern_clock.c. Allow architectures to implement alternatives or redo the function based on struct intr_event and likely intrcnt/intrnames could be removed. Given the above difficulty, I suspect this would be a Good Thing.

[mhorne]

On its own, this change is bogus. It is, as you note, present only in an unused code path, for an issue which you cannot demonstrate or clearly describe how it would occur. Patches fixing only theoretical problems will almost always be met with push-back, and are an unnecessary tax on limited reviewer resources.

Please, make sure you have something to put in the "Testing Done" section, or else your changes will continue to stall in review.

[ehem_freebsd_m5p.com]

The real lurking issue is handled by D36610. Abandoning D35608 as it is unlikely to ever see the light of day.