[RFC] use a shared lock for VOP_GETEXTATTR

[Konstantin Belousov]

On Wed, Mar 27, 2013 at 10:40:16PM -0700, mdf at FreeBSD.org wrote:
> On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf at FreeBSD.org wrote:
> >> VOP_GETEXTATTR is currently called with an exclusive lock, which seems
> >> like overkill for what is essentially a read operation.  I had a look
> >> over the various in-tree filesystems and it didn't look like any of
> >> them will have a problem if a shared-mode lock is used for
> >> vop_getextattr.
> >>
> >> Does anyone know otherwise?  Is someone using extended attributes
> >> regularly who can test this?
> >
> > I think this change should be fine. At least it seems to for UFS.
> >
> > What other filesystems did you audited ?
> 
> I looked over zfs, pseudofs, unionfs, ffs/ufs.  None seemed to have
> any asserts on the lock type nor anything that looked like it would
> try to modify anything.  zfs, I think it was, even used VOP_ISLOCKED
> to get the lock type in one path (but I think that was after a
> lookup(), so it may have been on a different vnode).

VOPs usually do not assert the lock state, unless the explicit unlock/lock
is done, or some other call is made which asserts the lock. If zfs is fine
from your inspection, I think that the patch can be committed without an
issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20130328/1522f850/attachment.sig>