From owner-freebsd-fs@FreeBSD.ORG Thu Mar 28 01:31:09 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF1CF2BE; Thu, 28 Mar 2013 01:31:09 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by mx1.freebsd.org (Postfix) with ESMTP id 85D82E7E; Thu, 28 Mar 2013 01:31:09 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id da11so4094046qeb.29 for ; Wed, 27 Mar 2013 18:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vdSZtIZ5gTOVdSyF1yAT0BDvDa1QbESKB2quzyyRWo0=; b=iRvfR5L8lq+mPtSboXQ6tFwc4fUIK3WWR93fsT2tu9BmAGxeUXlo1P7HYW00sRBLWu H3bghK6Ckt7BwM4qiq6nm5GGgr14rEUnz9Fnxzbl7HCOGGyzt6DNqzBLOM5Ft7qJFFGy LpeaDu362inc1S5ChWfA6lW3RAiMCDUGglTrGc4iAq8uC4balLkmqYL4O2t5hYrqQu3v HSwIP4dpQf6kAmBaU3sC7oJs39apUwQSJzosbfEOvkJno2f1x3aGIvN4B1OrXy+AmM9j am42tCSXGIvnAdW9ZGr0eGBqrnjLLR5o3DKDgi+eS6G3GMG6M1JF/VTMTH1oM1RtNtJG EqWQ== MIME-Version: 1.0 X-Received: by 10.229.118.66 with SMTP id u2mr849759qcq.102.1364434263281; Wed, 27 Mar 2013 18:31:03 -0700 (PDT) Received: by 10.229.253.201 with HTTP; Wed, 27 Mar 2013 18:31:02 -0700 (PDT) Date: Wed, 27 Mar 2013 18:31:02 -0700 Message-ID: Subject: [RFC] use a shared lock for VOP_GETEXTATTR From: Matthew Fleming To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd5ccee951c6904d8f21bef X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 01:31:09 -0000 --000e0cd5ccee951c6904d8f21bef 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? Thanks, matthew --000e0cd5ccee951c6904d8f21bef 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_het8w2zm0 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== --000e0cd5ccee951c6904d8f21bef--