Re: [RFC] use a shared lock for VOP_GETEXTATTR
--XsW72sOHJGfuGe9h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 10:40:16PM -0700, mdf@FreeBSD.org wrote:
> On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov
> <kostikbel@gmail.com> wrote:
> > On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf@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 ?
>=20
> 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
=66rom your inspection, I think that the patch can be committed without an
issue.
--XsW72sOHJGfuGe9h
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iQIcBAEBAgAGBQJRU9uHAAoJEJDCuSvBvK1B5+oP/1A+CLA6d4Uj4cBEZH71gsPd
nI4QzQ8Mr1zOP2yLH9clbtT29NDXb/zwbFRzHFh4R8UD8mnQzr6Aebkt+obzctCz
a3JT6WF4D+uCPL+E5cUTaVpaA/8guQO+MlP3ECN21KqqDI5mAfHEshSLcbHeJi2Q
MAmWID6Wn0ONIk2027pjP2rayQE0ECpKEoEuahPNeHjTecstY2EKA4nITXb+dVLj
mgC7zpHlLeH0PD6/PM47RBIc/AqTi6B2Mj3swYuIEUo2PJYMzNG+pdl9IYg+VNzZ
KklxpSNRkBwUGfPGLiIKxR3Bvr404x3/C4rBWGyyIDYs75q5C4pUfUnKImJ8aerg
fp4gfwSZ58xMV5yNUIPQRuKh7pQdf6ha5Kc4THEBKk4Cl4KL0SCRk1NS/vnn+IIR
nDYog1g6h421Nvx9EIP/SoyYHlyni0J8Q9DDvu6eQEyUGwQdBkWqg8aKXF/7pRFr
cjJTPHZ23zCbNQF+h4kIyrkqgcUYr1PQeCw77YN17rhfR7gfgAVoUxdCI6B+Un62
Pl/X9vte63S/LpbAu584ItlOrVFzFMXoYM+lcTmqra2InKtl0CtyzUg7lDrsuii8
j1SnN/EPuWJB8VNIWHp4n9O/Z5iHURbJLz1sT0POp+bocFiTHa8Nas8GGB8wcCYQ
pqdGv5PhGVeLuQWQm+nT
=2MpL
-----END PGP SIGNATURE-----
--XsW72sOHJGfuGe9h--
討論串 (同標題文章)
完整討論串 (本文為第 4 之 4 篇)：