Date: Wed, 24 Sep 2014 20:16:06 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: arch@FreeBSD.org Subject: KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread Message-ID: <54236CD6.4050807@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've placed 2 reviews out in relation to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193696: 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 0xfffffe349= 829a340 > 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+0x= de/frame 0xfffffe349829aaa0 > cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xf= ffffe349829aac0 > 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 =3D 0, rsp =3D 0xfffffe349829acb0, rbp =3D 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 0xfffffe349= 829a2d0 > 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+0x= de/frame 0xfffffe349829aaa0 > cam_periph_release_locked() at cam_periph_release_locked+0x1b/frame 0xf= ffffe349829aac0 > 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 =3D 0, rsp =3D 0xfffffe349829acb0, rbp =3D 0 --- > (ada3:ahcich3:0:0:0): Periph destroyed --=20 Regards, Bryan Drewery --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUI2zWAAoJEDXXcbtuRpfPnREH/RM90JrAEzfoiZR8j8+lP3Zm m1PxVrLFZs4pDsMS0CXMJCtlL1Q/Cna9yo9c6XXk/hOCT9jrZWrgGiVTJMCdVGVh jdePOukAITndpzr1ayJH1E0h5OBtmn0r+0BVgAmEpMk6bW+35z+KqiwaGY2vS2m6 I0Saksc9hu58sSQdn3rR26moXJB1AO2VCxQkyhE+ir9Ac78NGeZcrUnR/KCfO9qE maVQkk8wF8T1GbW6UVHq38q0FC+PVXmAUqRUlzUv/acHRSxoa/JedFsY+SRRdIED qKaFXVx/iYCPzzyI6xAiNxTxNPt6IOSj79p8ovuZM7Y9IN34y7mAod6m8Sa8wXE= =KmhT -----END PGP SIGNATURE----- --X6QTeF9kHuvhb6A6pUts68oMf7cXfQl9O--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54236CD6.4050807>