[RFC] use a shared lock for VOP_GETEXTATTR

--20cf3074b9a4f2ad3c04d8f23328
Content-Type: text/plain; charset=ISO-8859-1

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?

[sorry if this is a duplicate; I first sent from my non-FreeBSD mail]

Thanks,
matthew

--20cf3074b9a4f2ad3c04d8f23328
Content-Type: application/octet-stream; 
	name="0001-Use-a-shared-lock-for-VOP_GETEXTATTR-as-it-is-a-read.patch"
Content-Disposition: attachment; 
	filename="0001-Use-a-shared-lock-for-VOP_GETEXTATTR-as-it-is-a-read.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_het94ldq0

RnJvbSBhYTZkNmM3MTZiZDE5Y2UzMmUzYjkwODcyN2ZiZGE2NWQzNDViN2FiIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0aGV3IEZsZW1pbmcgPG1kZkBGcmVlQlNELm9yZz4KRGF0
ZTogV2VkLCAyNyBNYXIgMjAxMyAxODoyMzoxNyAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIFVzZSBh
IHNoYXJlZCBsb2NrIGZvciBWT1BfR0VURVhUQVRUUiwgYXMgaXQgaXMgYSByZWFkLWxpa2Ugb3Bl
cmF0aW9uLgoKTUZDIGFmdGVyOgkxIHdlZWsKLS0tCiBzeXMva2Vybi92ZnNfZXh0YXR0ci5jIHwg
ICAgMiArLQogc3lzL2tlcm4vdmZzX3Zub3BzLmMgICB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdl
ZCwgMiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJu
L3Zmc19leHRhdHRyLmMgYi9zeXMva2Vybi92ZnNfZXh0YXR0ci5jCmluZGV4IDg1ZmM4MzkuLjcw
MGE3MGMgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3Zmc19leHRhdHRyLmMKKysrIGIvc3lzL2tlcm4v
dmZzX2V4dGF0dHIuYwpAQCAtMzIxLDE3ICszMjEsMTcgQEAgZXh0YXR0cl9nZXRfdnAoc3RydWN0
IHZub2RlICp2cCwgaW50IGF0dHJuYW1lc3BhY2UsIGNvbnN0IGNoYXIgKmF0dHJuYW1lLAogICAg
IHZvaWQgKmRhdGEsIHNpemVfdCBuYnl0ZXMsIHN0cnVjdCB0aHJlYWQgKnRkKQogewogCXN0cnVj
dCB1aW8gYXVpbywgKmF1aW9wOwogCXN0cnVjdCBpb3ZlYyBhaW92OwogCXNzaXplX3QgY250Owog
CXNpemVfdCBzaXplLCAqc2l6ZXA7CiAJaW50IGVycm9yOwogCi0Jdm5fbG9jayh2cCwgTEtfRVhD
TFVTSVZFIHwgTEtfUkVUUlkpOworCXZuX2xvY2sodnAsIExLX1NIQVJFRCB8IExLX1JFVFJZKTsK
IAogCS8qCiAJICogU2xpZ2h0bHkgdW51c3VhbCBzZW1hbnRpY3M6IGlmIHRoZSB1c2VyIHByb3Zp
ZGVzIGEgTlVMTCBkYXRhCiAJICogcG9pbnRlciwgdGhleSBkb24ndCB3YW50IHRvIHJlY2VpdmUg
dGhlIGRhdGEsIGp1c3QgdGhlIG1heGltdW0KIAkgKiByZWFkIGxlbmd0aC4KIAkgKi8KIAlhdWlv
cCA9IE5VTEw7CiAJc2l6ZXAgPSBOVUxMOwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vdmZzX3Zub3Bz
LmMgYi9zeXMva2Vybi92ZnNfdm5vcHMuYwppbmRleCBjOGY4MzJmLi42ODQ5NzMwIDEwMDY0NAot
LS0gYS9zeXMva2Vybi92ZnNfdm5vcHMuYworKysgYi9zeXMva2Vybi92ZnNfdm5vcHMuYwpAQCAt
MTc1MywxNyArMTc1MywxNyBAQCB2bl9leHRhdHRyX2dldChzdHJ1Y3Qgdm5vZGUgKnZwLCBpbnQg
aW9mbGcsIGludCBhdHRybmFtZXNwYWNlLAogCWF1aW8udWlvX2lvdmNudCA9IDE7CiAJYXVpby51
aW9fcncgPSBVSU9fUkVBRDsKIAlhdWlvLnVpb19zZWdmbGcgPSBVSU9fU1lTU1BBQ0U7CiAJYXVp
by51aW9fdGQgPSB0ZDsKIAlhdWlvLnVpb19vZmZzZXQgPSAwOwogCWF1aW8udWlvX3Jlc2lkID0g
KmJ1ZmxlbjsKIAogCWlmICgoaW9mbGcgJiBJT19OT0RFTE9DS0VEKSA9PSAwKQotCQl2bl9sb2Nr
KHZwLCBMS19FWENMVVNJVkUgfCBMS19SRVRSWSk7CisJCXZuX2xvY2sodnAsIExLX1NIQVJFRCB8
IExLX1JFVFJZKTsKIAogCUFTU0VSVF9WT1BfTE9DS0VEKHZwLCAiSU9fTk9ERUxPQ0tFRCB3aXRo
IG5vIHZwIGxvY2sgaGVsZCIpOwogCiAJLyogYXV0aG9yaXplIGF0dHJpYnV0ZSByZXRyaWV2YWwg
YXMga2VybmVsICovCiAJZXJyb3IgPSBWT1BfR0VURVhUQVRUUih2cCwgYXR0cm5hbWVzcGFjZSwg
YXR0cm5hbWUsICZhdWlvLCBOVUxMLCBOVUxMLAogCSAgICB0ZCk7CiAKIAlpZiAoKGlvZmxnICYg
SU9fTk9ERUxPQ0tFRCkgPT0gMCkKLS0gCjEuNy4zLjIKCg==
--20cf3074b9a4f2ad3c04d8f23328
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
--20cf3074b9a4f2ad3c04d8f23328--