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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC