Re: pfind() in ithread handler



2008/2/28, Yuri Pankov <yuri.pankov@xxxxxxxxx>:
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.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: pfind() in ithread handler
    ... but thread marked as sleeping prohibited ... ithreads cannot perform unbound sleeps and pfindneeds to access to ... allproc_lock which is a sx lock and *performs* an unbound sleep, ... it sounds like allproc_lock and other similar locks are just ...
    (freebsd-hackers)
  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • Re: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges
    ... Locks are only held for truncate and huge pages. ... If not for the sanity of the driver ... struct mmu_gather *tlb; ... how to you resolve the case where you are not allowed to sleep? ...
    (Linux-Kernel)
  • Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c
    ... should we rather put this code in the generic kernel code so that other ... I didn't find a clean way out of the starvation issue. ... > is seldom okay to sleep. ... > might be holding other locks and must not sleep in the shared path). ...
    (freebsd-net)

Quantcast