Date: Thu, 28 Mar 2013 07:56:23 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: mdf@FreeBSD.org Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] use a shared lock for VOP_GETEXTATTR Message-ID: <20130328055623.GG3794@kib.kiev.ua> In-Reply-To: <CAMBSHm_Rbw=0-nA%2Bn5JoT68L_4%2BKvAZM-o%2BS%2B01TqFZKacjfgQ@mail.gmail.com> References: <CAMBSHm8Akz2-tUhjYm9%2BH3YTN31N8=OhGHX1ZpdV4-VixFQm%2BQ@mail.gmail.com> <CAMBSHm9VgD9Pcmiap3Cy1eW8GD9k06q%2BsCzaSJ%2B_wyA6ZFioTA@mail.gmail.com> <20130328053205.GF3794@kib.kiev.ua> <CAMBSHm_Rbw=0-nA%2Bn5JoT68L_4%2BKvAZM-o%2BS%2B01TqFZKacjfgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130328055623.GG3794>