From owner-freebsd-arch Wed Jan 17 23:30:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id BD4C237B402; Wed, 17 Jan 2001 23:30:11 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0I7Y0s67081; Wed, 17 Jan 2001 23:34:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <001d01c08119$a62482b0$1f90c918@jehovah> Date: Wed, 17 Jan 2001 23:29:57 -0800 (PST) From: John Baldwin To: Bosko Milekic Subject: RE: mtx_init: MTX_RECURSE and potential SMP troublespots Cc: jasone@FreeBSD.org, arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Jan-01 Bosko Milekic wrote: > sys/dev/ichsmb passes MTX_NORECURSE to mtx_init(), when it's only supposed to > be passed to mtx_exit(). Apparently, this is not in mutex(9) [yet?] Also, MTX_NORECURSE is only useful on spin mutexes. If you compile a kernel with MUTEX_DEBUG and ichsmb, it panics during boot. All the MTX_NORECURSE flags just need to die here. > sys/dev/isp probably calls tsleep() with a mutex held and has a wakeup() for > that sleep surrounded by the mutex lock's acquire/drop. It should use msleep() instead then. The mutex around wakeup() isn't wrong, though not necessarily optimal. > sys/dev/pccbb seems to protect wakeup() calls w/ a mutex enter/exit. This is > odd because just code is typically not supposed to be protected with a mutex. > This may be a problem because I believe I saw this code drop the mutex before > calling tsleep() which may be a race because in this case, a wakeup() can > come before the actual tsleep() is entered (or before the switch happens) and > therefore the thread will go to sleep even if a wakeup() was already issued > just prior to. You have to use msleep() instead of mtx_exit/tsleep(). I have several other changes to the pccbb mutexes in my tree however. :) > sys/dev/yarrow.c "may" be violating lock order (there _may_ be a lock order > reversal); the fact that printf()s are surrounded with Giant lock enter/exit > and that some of the routines containing the printf() calls are called with > the driver's lock held and that some of them aren't may be a problem if those > that are not do attempt to acquire the driver lock and are entered with Giant > already held (from somewhere). There may be a lock reversal; but I haven't > been able to investigate sufficiently to be able to claim this with absolute > certainty. Hmm, haven't looked at this yet. > Regards, > Bosko. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message