From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <599f06db0805290640r7d8b7f8ajc413748a22508eac@mail.gmail.com> Date: Thu, 29 May 2008 15:40:50 +0200 From: "Gorka Guardiola" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: [9fans] ilock funny? Topicbox-Message-UUID: af1a88a4-ead3-11e9-9d60-3106f5b1d025 On Thu, May 29, 2008 at 3:34 AM, erik quanstrom wrote: > in this situation there are 128 kernel procs that all > increment the same counter with some code > that looks like so: > > void > incref(void) > { > ilock(&somelock); > someval++; > iunlock(&somelock); > } > > (i realize there are probablly better ways to do this.) > there is a similar function to decrease the value. > other than this, there are no references to somelock. > > what i'm seeing is a panic with someval = 5. (gathered > from the fact that someval is stored immediately after > the somelock and is dumped with dumplockmem()) > and the panic message: What you say simply cannot happen if your code was correct (the one you are not showing us :-)). isilock is a variable set by the lock to tainted as ilock instead of lock. Having isilock=1 onlys happen After the lock has been acquired by someone. The lock is checked with a tas() which I assume works because everything is based on it. My guess is that you have the lock uninitialized (key is not what it should be), so key has a bogus value and that is where your problems start. Zeroing the lock before using it should do the trick. HTH. -- - curiosity sKilled the cat