On 2 Feb 2009, at 19:09 , Julian Elischer wrote:
It says "non-sleepable locks", yet it classifies click_instance as sleep mutex. I think witness code should emit messages which are more clear.It is confusing, but you can't do an M_WAITOK malloc while holding a mutex. Basically, sleeping actually means calling "*sleep() (such as mtx_sleep()) or cv_*wait*()". Blocking on a mutex is not sleeping, it's "blocking". Some locks (such as sx(9)) do "sleep" when you contest them. In the scheduler, sleeping and blocking are actually quite different (blocking uses turnstiles that handle priority inversions via priority propagation, sleeping uses sleep queues which do not do any of that). The underyling idea is that mutexes should be held for "short" periods of time, and that any sleeps are potentially unbounded. Holding a mutex while sleeping could result in a mutex being held for a long time.the locking overview page man 9 locking tries to explain this..I've been pestering John to proofread it and make suggestiosn for a while now.
Thanks John and Julian. I agree, man pages should be more clear :)I've switched from using mtx to sx locks, since they offer sleeping while hold.
Unfortunately, I've ran into something really weird now, when I unload the module:
---8<--- #0 doadump () at pcpu.h:195#1 0xffffffff8049ef98 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418
#2 0xffffffff8049f429 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574#3 0xffffffff8075cd26 in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:764#4 0xffffffff8075da62 in trap (frame=0xffffffff87699940) at /usr/src/ sys/amd64/amd64/trap.c:290 #5 0xffffffff80743bfe in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:209
#6 0xffffffff8052a411 in strcmp (s1=0xffffffff80824a0c "sigacts",s2=0xffffffff877cd3a9 <Address 0xffffffff877cd3a9 out of bounds>) at /usr/src/sys/libkern/strcmp.c:45 #7 0xffffffff804d7c61 in enroll (description=0xffffffff80824a0c "sigacts", lock_class=0xffffffff80a19fe0)
at /usr/src/sys/kern/subr_witness.c:1439
#8 0xffffffff804d7fb1 in witness_init (lock=0xffffff00016f4ca8) at /
usr/src/sys/kern/subr_witness.c:618
#9 0xffffffff8049fd31 in sigacts_alloc () at /usr/src/sys/kern/
kern_sig.c:3280
#10 0xffffffff80481121 in fork1 (td=0xffffff0001384a50, flags=20,
pages=Variable "pages" is not available.
) at /usr/src/sys/kern/kern_fork.c:453#11 0xffffffff80481450 in fork (td=0xffffff0001384a50, uap=Variable "uap" is not available.
) at /usr/src/sys/kern/kern_fork.c:106#12 0xffffffff8075d260 in syscall (frame=0xffffffff87699c80) at /usr/ src/sys/amd64/amd64/trap.c:907 #13 0xffffffff80743e0b in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:330
#14 0x0000000800ca0a6c in ?? () --->8--- and in fra 7: (kgdb) p *w$5 = {w_name = 0xffffffff877cd3a9 <Address 0xffffffff877cd3a9 out of bounds>, w_class = 0xffffffff80a19fe0, w_list = { stqe_next = 0xffffffff80accce0}, w_typelist = {stqe_next = 0xffffffff80accce0}, w_children = 0x0, w_file = 0xffffffff877d1fa0 <Address 0xffffffff877d1fa0 out of bounds>, w_line = 307, w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0', w_other_squawked = 0 '\0', w_same_squawked = 0 '\0', w_displayed = 0 '\0'}
(kgdb) p *w->w_class$6 = {lc_name = 0xffffffff808564e0 "sleep mutex", lc_flags = 9, lc_ddb_show = 0xffffffff80492e6b <db_show_mtx>, lc_lock = 0xffffffff804938be <lock_mtx>, lc_unlock = 0xffffffff804933fc <unlock_mtx>}
This happens after modevent exists.What puzzles me here is w_refcount of 2, while w_name is out of bounds. Locks I've created I properly destroyed (at least I think I did :)).
Cheers, Nikola _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
