From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 12:38:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08FFD16A4CE; Wed, 14 Jan 2004 12:38:33 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70D4B43D6E; Wed, 14 Jan 2004 12:38:21 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i0EKcD7E040320; Wed, 14 Jan 2004 12:38:17 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401142038.i0EKcD7E040320@gw.catspoiler.org> Date: Wed, 14 Jan 2004 12:38:13 -0800 (PST) From: Don Lewis To: tjr@FreeBSD.org In-Reply-To: <20040114140818.GA15471@cat.robbins.dropbear.id.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: simplifying linux_emul_convpath() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:38:33 -0000 On 15 Jan, Tim Robbins wrote: > On Wed, Jan 14, 2004 at 05:08:51AM -0800, Don Lewis wrote: > >> I just stumbled across a vnode locking violation in >> linux_emul_convpath(). Rather than locking and unlocking each vnode for >> the VOP_GETATTR() calls, is there any reason that this code should not >> be simplified to just compare the vnode pointers rather than fetching >> the vnode attributes and comparing the attributes for equality. > > I'm having trouble convincing myself that comparing vnode pointers > would work with stackable filesystems. Then again, null_getattr() > changes va_fsid, so linux_emul_convpath() may not handle stacking > properly right now anyway. They won't compare equal in either case, but I think that is what you want in this case anyway. I don't think we want a Linux application opening a file to trigger the match code if it does a lookup on /some/other/path if that location is a nullfs mounted version of of /compat/linux.