From owner-freebsd-hackers Wed Jan 6 10:11:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15958 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 10:11:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15951 for ; Wed, 6 Jan 1999 10:10:59 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA20594; Wed, 6 Jan 1999 11:10:21 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd020396; Wed Jan 6 11:10:06 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA06921; Wed, 6 Jan 1999 11:09:54 -0700 (MST) From: Terry Lambert Message-Id: <199901061809.LAA06921@usr05.primenet.com> Subject: Re: Unlocking vnodes from different processes To: grog@lemis.com (Greg Lehey) Date: Wed, 6 Jan 1999 18:09:54 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990106123627.N78349@freebie.lemis.com> from "Greg Lehey" at Jan 6, 99 12:36:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In Vinum, I sometimes need to lock a vnode in one process and unlock > it in another. Since 3.0, I've been getting panics when I do this: > > panicstr: lockmgr: pid 429, not exclusive lock holder 428 unlocking Yeah; that's expected behaviour. > Can I assume that the other parameters (flag, p) to VOP_UNLOCK will > enable me to do this anyway? The p parameter is the process doing the locking or unlocking. You could technically lie to the thing about the curproc to do the unlock. I would *not* recommend this. > Also, since I don't perform the lock directly (it happens as a > side-effect of opening the vnode), is there a kosher way to find > out what process locked the vnode? You can dereference the lock and look. As long as you don't sleep, you don't give the other process an opportunity to run, and therefore the lock is not in danger of disappearing out from under you. Again, I wouldn't recommend this. It's dirty, and it'll complicate the heck out of things for somone later when they go in not expecting a dependency on the non-sleep or other side effects. Are these kernel processes? Can you maybe lock as a single kernel process, and then queue the releases to that process instead, waking the queueing process back up after the unlock? There's got to be a different approach that doesn't require yielding lock ownership between processes. Alternately, add a function to the lock manager to implement explicit yielding, and then call it to implement the yield... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message