Date: Sat, 14 Mar 1998 23:53:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: karl@mcs.net (Karl Denninger) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Odd problem we're seeing here Message-ID: <199803142353.QAA20032@usr05.primenet.com> In-Reply-To: <19980314113743.62444@mcs.net> from "Karl Denninger" at Mar 14, 98 11:37:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803142353.QAA20032>