KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread

Bryan Drewery bdrewery at FreeBSD.org
Thu Sep 25 02:57:20 UTC 2014


On 9/24/14, 8:16 PM, Bryan Drewery wrote:
> Hi,
>
> I've placed 2 reviews out in relation to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696:
>
> Add KASSERT_WARN which will work just like KASSERT except that no panic
> will occur.  My own expectation would be that any use of it would
> eventually be promoted to a full KASSERT.  It would only be used where
> the impact is not known yet on all hardware/devices.  We don't want to
> go adding a KASSERT and break boot for a whole class of systems.
>
>    https://reviews.freebsd.org/D829 - KASSERT_WARN
>
>
> Add the KASSERT_WARN to malloc(9) and uma_zalloc_arg(9) to ensure they
> are not called from a non-sleepable thread.  This is currently violated
> by cam, namely xpt_done_td() [see bug 193696].
>
>    https://reviews.freebsd.org/D830 - Use KASSERT_WARN in malloc(9) and
> uma_zalloc_arg(9)
>
> One flaw of this is that the KASSERT_WARN in malloc(9) is called, prints
> to console, continues, and then the uma_zalloc_arg(9) is called and does
> the same.  I thought perhaps the KASSERT_WARN could only be added in
> uma_zalloc_arg(9) for now and later the full KASSERT could be added in
> malloc(9), but I think this could miss some cases for memguard and maybe
> redzone uses.
>
> By the way, it was mentioned to me that the interrupt assert may be
> wrong but from my understanding the thread is in an interrupt context if
> td_intr_nesting_level>0, so the check seems fine to me.
>
> Example output:
>
>> ada3: <Hitachi HDT721010SLA360 ST6OA31B> s/n STF605MH1THSXW detached
>> KASSERT failed: malloc(M_WAITOK) in no_sleeping context
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349829a340
>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a3f0
>> _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a470
>> malloc() at malloc+0x2e4/frame 0xfffffe349829a4c0
>> g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510
>> g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580
>> adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0
>> cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0xde/frame 0xfffffe349829aaa0
>> cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xfffffe349829aac0
>> adadone() at adadone+0x26e/frame 0xfffffe349829ab20
>> xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60
>> xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0
>> fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0
>> --- trap 0, rip = 0, rsp = 0xfffffe349829acb0, rbp = 0 ---
>> KASSERT failed: uma_zalloc_arg(M_WAITOK) in no_sleeping context
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe349829a2d0
>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe349829a380
>> _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe349829a400
>> uma_zalloc_arg() at uma_zalloc_arg+0x6c5/frame 0xfffffe349829a470
>> malloc() at malloc+0x1c7/frame 0xfffffe349829a4c0
>> g_post_event_x() at g_post_event_x+0x84/frame 0xfffffe349829a510
>> g_post_event() at g_post_event+0x5d/frame 0xfffffe349829a580
>> adacleanup() at adacleanup+0x62/frame 0xfffffe349829a5a0
>> cam_periph_release_locked_buses() at cam_periph_release_locked_buses+0xde/frame 0xfffffe349829aaa0
>> cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xfffffe349829aac0
>> adadone() at adadone+0x26e/frame 0xfffffe349829ab20
>> xpt_done_process() at xpt_done_process+0x3a4/frame 0xfffffe349829ab60
>> xpt_done_td() at xpt_done_td+0x136/frame 0xfffffe349829abb0
>> fork_exit() at fork_exit+0x84/frame 0xfffffe349829abf0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe349829abf0
>> --- trap 0, rip = 0, rsp = 0xfffffe349829acb0, rbp = 0 ---
>> (ada3:ahcich3:0:0:0): Periph destroyed
>
>

Here's another one...

> KASSERT failed: malloc(M_WAITOK) in no_sleeping context
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe3509bd7800
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe3509bd78b0
> _kassert_panic() at _kassert_panic+0xd7/frame 0xfffffe3509bd7930
> malloc() at malloc+0x2e4/frame 0xfffffe3509bd7980
> zfs_dbgmsg() at zfs_dbgmsg+0x6d/frame 0xfffffe3509bd7a00
> spa_deadman() at spa_deadman+0x70/frame 0xfffffe3509bd7a30
> softclock_call_cc() at softclock_call_cc+0x19c/frame 0xfffffe3509bd7b10
> softclock() at softclock+0x47/frame 0xfffffe3509bd7b30
> intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfffffe3509bd7b70
> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe3509bd7bb0
> fork_exit() at fork_exit+0x84/frame 0xfffffe3509bd7bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe3509bd7bf0



-- 
Regards,
Bryan Drewery


More information about the freebsd-arch mailing list