From owner-freebsd-hackers Wed Jan 21 16:14:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA15279 for hackers-outgoing; Wed, 21 Jan 1998 16:14:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15256 for ; Wed, 21 Jan 1998 16:13:56 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA06373; Wed, 21 Jan 1998 19:13:34 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801220013.TAA06373@dyson.iquest.net> Subject: Re: Locking on disk slice I/O--yes, no or how? In-Reply-To: <199801212329.QAA12160@usr09.primenet.com> from Terry Lambert at "Jan 21, 98 11:29:29 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 21 Jan 1998 19:13:34 -0500 (EST) Cc: toor@dyson.iquest.net, tlambert@primenet.com, grog@lemis.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert said: > > > > I'm currently trying to perform low-level I/O to disk slices in a > > > > driver. I've read section 9 of the manual, which tells me that all > > > > reads and writes should be protected with a VOP_LOCK/VOP_UNLOCK pair. > > > > I've tried this, and get a panic: "lockmgr: locking against myself" > > > > > > Yick. Someone's trying to use the lockmgr for finer grained SMP > > > locking. That'll never work... it must have snuck in when I wasn't > > > looking. > > > > Terry, > > I think that your answer is orthogonal to the question asked. Also, > > lockmgr is perfect (except for being slightly high overhead) for the purpose > > that it is being used. I am moving towards a TSM scheme for both better > > UP and SMP performance. > > > > When my work settles down, I will try to help with some of the questions that > > have come across my mailbox in the last week or so. > > He can't call VOP_LOCK because he's in the kernel, and there's a > different lock asserted because of the way he got there. > Yes he can call VOP_LOCK, if done properly. > > Either you're supposed to call VOP_LOCK to protect the vnode from being > reentered, or you're not, right? > Yes... > > IMO, he shouldn't be getting the panic, and it should work, unless > he's trying to call the thing at interrupt time from the driver for > the device he's attempting to write to. > Yes. > > The panic occurs because, in an attempt to get finer grained locking, > the lock space was normalized against deadlocks by unifying it instead > of adding hierarchy. > Not necessarily. I don't have time to properly answer the questions. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.