Date: Wed, 24 Sep 2014 21:57:17 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: arch@FreeBSD.org Subject: Re: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread Message-ID: <5423848D.9050602@FreeBSD.org> In-Reply-To: <54236CD6.4050807@FreeBSD.org> References: <54236CD6.4050807@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5423848D.9050602>