Page MenuHomeFreeBSD

kern: malloc: fix panic on M_WAITOK during THREAD_NO_SLEEPING()

Authored by kevans on Mar 8 2021, 6:19 AM.



Simple condition flip; we wanted to panic here after epoch_trace_list().

Diff Detail

R10 FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kevans requested review of this revision.Mar 8 2021, 6:19 AM
markj added inline comments.

BTW, I am not sure why this assertion is predicated on M_WAITOK being set. It should always be true, I'd think.

This revision is now accepted and ready to land.Mar 8 2021, 5:14 PM

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.