I'm not necessarily seeing where this assertion is useful at all, to be honest. I know nothing about the different kinds of interrupt handlers, but almost everywhere that touches td_intr_nesting_level[0] also puts us in a critical section to hit the KASSERT just below this block.

[0] the exception seems to be that ipi_bitmap_handler() over in x86/x86/mp_x86.c will only do so for hardclock. Again, not familiar, but that seems to lead to an inconsistency in expectations for all of the other ipi handlers w.r.t. malloc(9) (and maybe others?), but I would suspect that it doesn't matter at all in practice as they shouldn't be allocating anything.

There is also smp_rendezvous_action(), which gets called from an interrupt handler without bumping intr_nesting_level but enters a critical section.

In general I wouldn't assume that td_intr_nesting_level != 0 implies that td_critnest != 0. IMO we should simply add this condition to the assertion below, i.e., (curthread->td_critnest != 0 && td->td_intr_nesting_level) || SCHEDULER_STOPPED().

But of course this isn't directly related to the diff at hand.