Date: Wed, 17 Oct 2007 11:40:47 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-current@freebsd.org Cc: Kris Kennaway <kris@FreeBSD.org> Subject: Re: 7.0 CURRENT, need help with panic: Trying sleep, but thread marked as sleeping prohibited Message-ID: <20071017113703.P94637@fledge.watson.org> In-Reply-To: <648464572.20071016235832@masm.elcom.ru> References: <471530484.20071014172230@masm.elcom.ru> <47121CCA.6080202@FreeBSD.org> <1946103758.20071016165321@masm.elcom.ru> <47150B2C.7090905@FreeBSD.org> <648464572.20071016235832@masm.elcom.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Oct 2007, Victor M. Blood wrote: >> Do you have the debugging options (INVARIANTS and INVARIANT_SUPPORT) >> enabled? They are now disabled in RELENG_7. If not you will just get a >> deadlock when you are unlucky :) > Yes, all debug options are stay by default. > = KERN > ... > # Debugging for use in -current > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > ... > = END KERN > > I have updated ipfilter to 4.1.27 until cvsup with tag=RELING_7 and sources > was from 10.10.2007 which system shows me panic with _sx_sleep() and > _rw_sleep() with ipf 4.1.23. After some tests :)) /ping, smbfs, telnet, > etc.../ Update of ipfilter was finished at 17:00 GMT+3, now: # uptime 23:51 > up 7:12, 2 users, load averages: 1,32 1,23 1,09 > > Now I'm have update CVS-tree, and build world for RELENG_7. With ipfilter > 4.1.23 system stay alive 1-2 min with inet work, I have been compelled to > disable ipfilter (ipf -D) for work with network. While any failures are not > present, all works normally. The bug in ipfilter has to do with using a sleepable lock class in an interrupt or a software interrupt thread. This can lead to deadlocks, although is relatively unlikely to do so, so is reported by invariants testing as a fatal condition. The panic won't turn up without invariants enabled, and in practice the deadlock is quite unlikely, but reflects a violation of the assumptions under which kernel synchronization is designed to work. Switching to a non-sleepable lock class doesn't provide an instant solution because the non-sleepable lock will then be held over a potentially sleepable path for managing the firewall from user space (if a copyin/copyout results in a page fault that sleeps waiting on disk I/O, or worse, network I/O from network-backed swap, which could lead directly to the deadlock). Chances are, this is relatively easy to fix, but someone needs to do that -- ideally someone very familiar with ipfilter. :-) In practice, I wouldn't expect the deadlock to occur much/at all, FWIW, so users with common configurations won't run into a problem, so with invariants disabled you may well be fine. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017113703.P94637>