From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 4 16:05:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC18106564A for ; Wed, 4 Feb 2009 16:05:05 +0000 (UTC) (envelope-from laladelausanne@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 46E968FC1A for ; Wed, 4 Feb 2009 16:05:05 +0000 (UTC) (envelope-from laladelausanne@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so314400eyd.7 for ; Wed, 04 Feb 2009 08:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=UQ8wr7asOW5lZU3w8lfWIAXtLRvLWu1TdPzbBzWuKf8=; b=ooXU51LANKyQtRZwi9jPZmer3vHhxBcXq1Io+t1a3i8+010pFJB5yew10ZqocmvotN XABl76QREEbr4W1xXt4dO2LeCHqymT2FIyshu6rbgDe0AImRQEfe4fyRJDZDYwy/nSbj 3H9e5QEH1XEBen6GA+/r8XQ1MhlG7vRTiFi2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=IgxAR8IXEKGBa8tsF9b80TZgSp/aGgllngz/2Dtn9g62BYV/hSxukcmH3fV4tq22+j k8gIIQiLeYKRO1rgMri3EArzH7CKz17MC2Ysk1IY3NJQbdWAS3v9uJgl7PJoQcAoK52T dVIOUyqugkgeBbDK9FQIK8SHhYrYkuUH6Ligg= Received: by 10.86.51.10 with SMTP id y10mr1390151fgy.9.1233763504240; Wed, 04 Feb 2009 08:05:04 -0800 (PST) Received: from nslpc5.epfl.ch (nslpc5.epfl.ch [128.178.149.20]) by mx.google.com with ESMTPS id d6sm6956251fga.59.2009.02.04.08.05.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Feb 2009 08:05:03 -0800 (PST) Message-Id: From: =?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?= To: freebsd-hackers@freebsd.org In-Reply-To: <498736C2.3040207@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 17:05:02 +0100 References: <02026848-7F83-405C-B4F3-EDD8B47DA294@gmail.com> <32679C0A-28C1-4D7A-950C-580787F3971D@gmail.com> <200902020845.21773.jhb@freebsd.org> <498736C2.3040207@elischer.org> X-Mailer: Apple Mail (2.930.3) Subject: Re: blockable sleep lock (sleep mutex) 16 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:05:06 -0000 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
) 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
, w_class = 0xffffffff80a19fe0, w_list = { stqe_next = 0xffffffff80accce0}, w_typelist = {stqe_next = 0xffffffff80accce0}, w_children = 0x0, w_file = 0xffffffff877d1fa0
, 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 , lc_lock = 0xffffffff804938be , lc_unlock = 0xffffffff804933fc } 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