From owner-freebsd-hackers Sat Mar 14 16:51:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09250 for freebsd-hackers-outgoing; Sat, 14 Mar 1998 16:51:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09243 for ; Sat, 14 Mar 1998 16:51:35 -0800 (PST) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id SAA16006; Sat, 14 Mar 1998 18:51:36 -0600 (CST) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id SAA29142; Sat, 14 Mar 1998 18:51:36 -0600 (CST) Message-ID: <19980314185135.47922@mcs.net> Date: Sat, 14 Mar 1998 18:51:35 -0600 From: Karl Denninger To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: Odd problem we're seeing here References: <19980314113743.62444@mcs.net> <199803142353.QAA20032@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199803142353.QAA20032@usr05.primenet.com>; from Terry Lambert on Sat, Mar 14, 1998 at 11:53:04PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 14, 1998 at 11:53:04PM +0000, Terry Lambert wrote: > > Hmmm... I've looked at these patches, and have a couple of questions... > > > > You note that the vnode "should" be locked when the LEASE call is made - yet > > in kern_ktrace.c, you call the LEASE request *before* the lock is asserted. > > Is this correct, and why? Wouldn't you want to lock the object first to > > prevent setting up another potential race condition? Also, ktrace.c > > isn't a "standard" execution path, is it? > > The ordering is problematic in both cases because of the use of > vn_rdwr. > > I think the correct thing to do would be to get rid of the lock > and use the vn_write instead (which will VOP_LOCK, VOP_LEASE, > VOP_WRITE, and VOP_LOCK). The patch is glue. It won't cause > problems, except potentially on SMP NFS, which is already a > maze of twisty race conditions, all alike, because of the other > vn_rdwr/VOP_LEASE cases. > > > > link_aout.c applies to loading executables, and there it appears that I > > can't do any harm (or help) to the current situation by applying this. > > Yep. It won't help the problem you see, one way or the other. > > > > In the tty_tty.c case, you're also calling the lease before the lock. > > Unless I've missed something, this is the common entry point to any file > > I/O write request, correct. Again, isn't the order backwards here? > > Yes. But you are missing struct fileops; tty's are devices, not > VFS vp's. > > > > Other than this, does anyone know why weren't they committed? > > I think a better question to ask would be "do they fix/reduce the > problem you are seeing?". If they don't, then your problem isn't > a valid argument for committing them. > > Terry Lambert > terry@lambert.org What I'm trying to understand is why you're doing these in the order you are (instead of locking first, then doing the LEASE). I'm willing to attempt these (actually, only the one in the tty_tty.c file applies to most normal operations, correct?) but I'd like to *understand* how and why the order is as it is, given that it still looks "backwards" to me in terms of operation sequence. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message