Date: Thu, 18 Oct 2007 17:55:53 +0000 From: =?ISO-8859-1?Q?Stefan_Kr=FCger?= <stadtkind2@gmx.de> To: freebsd-current@freebsd.org Subject: Re: 7.0 CURRENT, need help with panic: Trying sleep, but thread marked as sleeping prohibited Message-ID: <47179E29.40705@gmx.de> In-Reply-To: <fa.187/RG1EqFc4coN17u60MdYabSk@ifi.uio.no> References: <fa.l1w/O6tl%2Bq8vkh74mNBLSppnk%2BY@ifi.uio.no> <fa.6RPqv1V4KbhKJ8QUJX%2Byh8jqufg@ifi.uio.no> <fa.1Y1yKu%2Bk3K1mBWaPsW8SVaGIw8U@ifi.uio.no> <fa.nj2Zhe1byVmDZxqjm%2B2hXX4lRVs@ifi.uio.no> <fa.uqOhrtcUKLyyqqg2wglLBSLhJxk@ifi.uio.no> <fa.187/RG1EqFc4coN17u60MdYabSk@ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > 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. :-) this someone could take a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=117182 (FreeBSD 7.0-PRERELEASE w/ ipfilter, sleeping thread panic)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47179E29.40705>