Re: [RFC] use a shared lock for VOP_GETEXTATTR

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 28 Mar 2013 07:56:23 +0200
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.

Received on Thu Mar 28 2013 - 04:56:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC