Date: Thu, 6 Mar 2008 08:09:47 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, Yuri Pankov <yuri.pankov@gmail.com> Subject: Re: pfind() in ithread handler Message-ID: <200803060809.47288.jhb@freebsd.org> In-Reply-To: <3bbf2fe10802280604t4266c0a9uaa0075689ce67632@mail.gmail.com> References: <20080228111222.GE92245@mail.irbisnet.ru> <3bbf2fe10802280604t4266c0a9uaa0075689ce67632@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 28 February 2008 09:04:55 am Attilio Rao wrote: > 2008/2/28, Yuri Pankov <yuri.pankov@gmail.com>: > > Hi, > > > > I'm trying to understand the cause of following panic. > > > > panic: Trying sleep, but thread marked as sleeping prohibited > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > panic() at panic+0x17d > > sleepq_add() at sleepq_add+0x2e1 > > _sx_slock_hard() at _sx_slock_hard+0x15d > > _sx_slock() at _sx_slock+0xc1 > > pfind() at pfind+0x24 > > saa_intr() at saa_intr+0x313 > > ithread_loop() at ithread_loop+0xda > > fork_exit() at fork_exit+0x12a > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffffffac3c0d30, rbp = 0 --- > > > > Can someone enlighten me on what is causing the panic and is it ok to > > use pfind() in interrupt handler (I have very limited understanding of > > kernel internals)? > > > > Code in question (taken from saa driver > > http://freebsd.ricin.com/ports/distfiles/kbtv-1.92.tbz) can be found at > > http://www.pastebin.ca/921830 > > ithreads cannot perform unbound sleeps and pfind() needs to access to > allproc_lock which is a sx lock and *performs* an unbound sleep, so > there is a mismatch. > > Btw, it sounds like allproc_lock and other similar locks are just > using an sx lock for *legacy*, they should be probabilly converted to > rwlock. > It also imposes little problems in the TTY layer, for example, where I > saw you need to use a unbounded sleeping primitive because of > processes locks acquisitions. > > A nice janitor task would be to convert these sx locks into rw and see > what happens. It would break. We hold these locks across malloc and other stuff in fork, etc. They are sx because of that, not for r/w semantics. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803060809.47288.jhb>