From owner-freebsd-hackers Sat Mar 14 15:53:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26121 for freebsd-hackers-outgoing; Sat, 14 Mar 1998 15:53:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26018 for ; Sat, 14 Mar 1998 15:53:18 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA23171; Sat, 14 Mar 1998 16:53:16 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd023139; Sat Mar 14 16:53:06 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA20032; Sat, 14 Mar 1998 16:53:04 -0700 (MST) From: Terry Lambert Message-Id: <199803142353.QAA20032@usr05.primenet.com> Subject: Re: Odd problem we're seeing here To: karl@mcs.net (Karl Denninger) Date: Sat, 14 Mar 1998 23:53:04 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <19980314113743.62444@mcs.net> from "Karl Denninger" at Mar 14, 98 11:37:43 am 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 > 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 --- 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