Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 May 2011 16:37:39 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: RFC: adding a lock flags argument to VFS_FHTOVP() for FreeBSD9
Message-ID:  <5718691.545130.1305751059426.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <20110517092011.GK48734@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, the flag to specify the locking mode does only specify the
> minimal
> locking requirements, and filesystem is allowed to upgrade it to the
> more strict lock type. E.g. UFS would only return shared lock if the
> vnode was found in hash, AFAIR. If not told otherwise, getnewvnode(9)
> forces lockmgr to convert all lock requests into exclusive.
> 
That's exactly what UFS does, but I did notice some inconsistencies
w.r.t. the various file systems.

For VFS_VGET(), ffs/cd9660/udf do basically the following:
1	error = vfs_hash_get(mp, ino, flags, curthread, vpp, NULL, NULL);
        ...
2	if ((flags & LK_TYPE_MASK) == LK_SHARED) {
		flags &= ~LK_TYPE_MASK;
		flags |= LK_EXCLUSIVE;
	}
	...
3	lockmgr(vp->v_vnlock, LK_EXCLUSIVE, NULL);
	...
4	error = vfs_hash_insert(vp, ino, flags, curthread, vpp, NULL, NULL);

but hpfs/ext2fs do something similar to the above, except
they omit step #2. (ie. They would do #4 with LK_SHARED, if
that was what flags is passed in as.)

Looking at vfs_hash_insert(), the "flags" argument is just
used for vget(), so it isn't obvious to me if it needs to
be LK_EXCLUSIVE or not.

So, does anyone know if this depend on the file system or are hpfs/ext2fs
broken?

Thanks in advance for any help with this, rick
ps: Fortunately, for my patch, I can just ignore the "flags"
    argument for VFS_FHTOVP() for the file systems I'm not
    sure about, so they'll just return LK_EXCLUSIVE locked
    vnodes.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5718691.545130.1305751059426.JavaMail.root>