Re: simplifying linux_emul_convpath()

On Wed, 14 Jan 2004, 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. 

For some time, I've been thinking of adding samefile() and fsamefile() 
system calls to FreeBSD, which would allow userspace applications to
determine if two names or file handles refer to the same object without
playing games with inode numbers, device ids, etc.  The reason to do this
would be that 32-bit inode numbers are subject to collision on large file
systems.  My initial implementation simply compared vnode pointers, but
that raises an interesting question about how stacked file systems should
be treated, and depends a lot on the semantics of the stacked file system,
really.  My leaning is that in general they should probably be treated as
different objects if they have different vnodes, because with the
exception of nullfs (and occasionally unionfs), that probably is the
desired semantic.  You could imagine introducing a VOP to ask "Are you the
same as this other vnode", and pointing it at both vnodes, but I think
that adds unnecessary complexity without a whole lot of benefit.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research