pfind() in ithread handler

[John Baldwin]

On Thursday 28 February 2008 09:04:55 am Attilio Rao wrote:
> 2008/2/28, Yuri Pankov <yuri.pankov at 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