Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252371 > unrolled thread

what's in nvdimm.git for v4.4?

Back to article view | Back to linux.kernel

Contents

  what's in nvdimm.git for v4.4? "Williams, Dan J" <dan.j.williams@intel.com> - 2015-10-21 01:40 +0200
    Re: what's in nvdimm.git for v4.4? Dave Chinner <david@fromorbit.com> - 2015-10-21 02:10 +0200
      Re: what's in nvdimm.git for v4.4? Dan Williams <dan.j.williams@intel.com> - 2015-10-21 02:40 +0200
        Re: what's in nvdimm.git for v4.4? Dave Chinner <david@fromorbit.com> - 2015-10-21 04:40 +0200
          Re: what's in nvdimm.git for v4.4? Dan Williams <dan.j.williams@intel.com> - 2015-10-21 05:20 +0200
        Re: what's in nvdimm.git for v4.4? Jan Kara <jack@suse.cz> - 2015-10-21 11:10 +0200
          Re: what's in nvdimm.git for v4.4? Dan Williams <dan.j.williams@intel.com> - 2015-10-21 19:00 +0200
          RE: what's in nvdimm.git for v4.4? "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2015-10-22 00:40 +0200
            Re: what's in nvdimm.git for v4.4? Dan Williams <dan.j.williams@intel.com> - 2015-10-22 01:00 +0200
    Re: what's in nvdimm.git for v4.4? Jens Axboe <axboe@fb.com> - 2015-10-21 19:50 +0200
      Re: what's in nvdimm.git for v4.4? Dan Williams <dan.j.williams@intel.com> - 2015-10-22 00:20 +0200
    Re: what's in nvdimm.git for v4.4? Ross Zwisler <ross.zwisler@linux.intel.com> - 2015-10-22 00:00 +0200

#1252371 — what's in nvdimm.git for v4.4?

SGVyZSBpcyBhIHN0YXR1cyBzdW1tYXJ5IG9mIHRoZSB0b3BpYy1icmFuY2hlcyBudmRpbW0uZ2l0
IGlzIHRyYWNraW5nDQpmb3IgdjQuNC4gIFVubGVzcyBpbmRpY2F0ZWQgdGhlc2UgYnJhbmNoZXMg
YXJlIG5vdCBwcmVzZW50IGluIC1uZXh0Lg0KUGxlYXNlIEFDSywgTkFLLCBvciBhc2sgZm9yIGEg
cmUtcG9zdCBvZiBhbnkgb2YgdGhlIGJlbG93IHRvIGRpc3Bvc2l0aW9uDQppdCBmb3IgdGhlIG1l
cmdlIHdpbmRvdy4NCg0KPT09DQpmb3ItNC40L2RheC1maXhlczoNCj09PQ0KDQogICAgICAgIENv
cmUgREFYIGFuZCBYRlMgZml4ZXMgZm9yIERBWCBsb2NraW5nLiAgVGhleSBhcmUgY2FycmllZCBp
bg0KICAgICAgICBudmRpbW0uZ2l0IGFzIGEgZGVwZW5kZW5jeSBvZiB0aGUgZm9yLTQuNC9kYXgt
Z3VwIGJyYW5jaC4NCiAgICAgICAgICAgICAgICANCiAgICAgICAgRGFuIFdpbGxpYW1zICgxKToN
CiAgICAgICAgICAgICAgcG1lbSwgZGF4OiBjbGVhbiB1cCBjbGVhcl9wbWVtKCkNCiAgICAgICAg
DQogICAgICAgIERhdmUgQ2hpbm5lciAoNSk6DQogICAgICAgICAgICAgIHhmczogZml4IGlub2Rl
IHNpemUgdXBkYXRlIG92ZXJmbG93IGluIHhmc19tYXBfZGlyZWN0KCkNCiAgICAgICAgICAgICAg
eGZzOiBpbnRyb2R1Y2UgQk1BUElfWkVSTyBmb3IgYWxsb2NhdGluZyB6ZXJvZWQgZXh0ZW50cw0K
ICAgICAgICAgICAgICB4ZnM6IERvbid0IHVzZSB1bndyaXR0ZW4gZXh0ZW50cyBmb3IgREFYDQog
ICAgICAgICAgICAgIHhmczogREFYIGRvZXMgbm90IHVzZSBJTyBjb21wbGV0aW9uIGNhbGxiYWNr
cw0KICAgICAgICAgICAgICB4ZnM6IGFkZCAtPnBmbl9ta3dyaXRlIHN1cHBvcnQgZm9yIERBWA0K
ICAgICAgICANCiAgICAgICAgUm9zcyBad2lzbGVyICgyKToNCiAgICAgICAgICAgICAgZGF4OiBk
YXhfcGZuX21rd3JpdGUoKSB0cnVuY2F0ZSByYWNlIGNoZWNrDQogICAgICAgICAgICAgIGV4dDI6
IEFkZCBsb2NraW5nIGZvciBEQVggZmF1bHRzDQoNCj09PQ0KZm9yLTQuNC9udW1hOg0KPT09DQoN
CiAgICAgICAgTWlub3IgYXBpIGNsZWFudXBzIHRoYXQgaGF2ZSBiZWVuIGFja2VkIGFuZCBwdWJs
aXNoZWQgaW4gLW5leHQNCiAgICAgICAgZm9yIGEgZmV3IHdlZWtzLg0KDQogICAgICAgIERhbiBX
aWxsaWFtcyAoNyk6DQogICAgICAgICAgICAgIHg4NiwgbW06IHF1aWV0IGFyY2hfYWRkX21lbW9y
eSgpDQogICAgICAgICAgICAgIHBtZW06IGtpbGwgbWVtcmVtYXBfcG1lbSgpDQogICAgICAgICAg
ICAgIGRldm1fbWVtdW5tYXA6IHVzZSBkZXZyZXNfcmVsZWFzZSgpDQogICAgICAgICAgICAgIGRl
dm1fbWVtcmVtYXA6IGNvbnZlcnQgdG8gcmV0dXJuIEVSUl9QVFINCiAgICAgICAgICAgICAgZGV2
bTogbWFrZSBhbGxvY2F0aW9ucyBudW1hIGF3YXJlIGJ5IGRlZmF1bHQNCiAgICAgICAgICAgICAg
ZGV2bV9tZW1yZW1hcF9wYWdlczogdXNlIG51bWFfbWVtX2lkDQogICAgICAgICAgICAgIHBtZW0s
IG1lbXJlbWFwOiBjb252ZXJ0IHRvIG51bWEgYXdhcmUgYWxsb2NhdGlvbnMNCiAgICAgICAgDQo9
PT0NCmZvci00LjQvZGF4LWd1cDogZ2V0X3VzZXJfcGFnZXMoKSBzdXBwb3J0IGZvciBkYXggbWFw
cGluZ3MNCmh0dHBzOi8vbGlzdHMuMDEub3JnL3BpcGVybWFpbC9saW51eC1udmRpbW0vMjAxNS1P
Y3RvYmVyLzAwMjM4Ny5odG1sDQo9PT0NCg0KICAgICAgICBOZWVkcyBhY2tzIGZyb20gY29yZSAt
bW0gZm9sa3MgcGFydGljdWxhcmx5IGZvcjoNCiAgICAgICAgICAgICAgICB4ODYsIG1tOiBpbnRy
b2R1Y2Ugdm1lbV9hbHRtYXAgdG8gYXVnbWVudA0KICAgICAgICAgICAgICAgIHZtZW1tYXBfcG9w
dWxhdGUoKQ0KICAgICAgICAgICAgICAgIG1tLCB4ODY6IGdldF91c2VyX3BhZ2VzKCkgZm9yIGRh
eCBtYXBwaW5ncw0KICAgICAgICANCiAgICAgICAgRGFuIFdpbGxpYW1zICgyMik6DQogICAgICAg
ICAgICAgIGJsb2NrOiBnZW5lcmljIHJlcXVlc3RfcXVldWUgcmVmZXJlbmNlIGNvdW50aW5nDQog
ICAgICAgICAgICAgIGRheDogaW5jcmVhc2UgZ3JhbnVsYXJpdHkgb2YgZGF4X2NsZWFyX2Jsb2Nr
cygpIG9wZXJhdGlvbnMNCiAgICAgICAgICAgICAgYmxvY2ssIGRheDogZml4IGxpZmV0aW1lIG9m
IGluLWtlcm5lbCBkYXggbWFwcGluZ3Mgd2l0aCBkYXhfbWFwX2F0b21pYygpDQogICAgICAgICAg
ICAgIG1tOiBpbnRyb2R1Y2UgX19nZXRfZGV2X3BhZ2VtYXAoKQ0KICAgICAgICAgICAgICB4ODYs
IG1tOiBpbnRyb2R1Y2Ugdm1lbV9hbHRtYXAgdG8gYXVnbWVudCB2bWVtbWFwX3BvcHVsYXRlKCkN
CiAgICAgICAgICAgICAgbGlibnZkaW1tLCBwZm4sIHBtZW06IGFsbG9jYXRlIG1lbW1hcCBhcnJh
eSBpbiBwZXJzaXN0ZW50IG1lbW9yeQ0KICAgICAgICAgICAgICBhdnIzMjogY29udmVydCB0byBh
c20tZ2VuZXJpYy9tZW1vcnlfbW9kZWwuaA0KICAgICAgICAgICAgICBodWdldGxiOiBmaXggY29t
cGlsZSBlcnJvciBvbiB0aWxlDQogICAgICAgICAgICAgIGZydjogZml4IGNvbXBpbGVyIHdhcm5p
bmcgZnJvbSBkZWZpbml0aW9uIG9mIF9fcG1kKCkNCiAgICAgICAgICAgICAgdW06IGtpbGwgcGZu
X3QNCiAgICAgICAgICAgICAga3ZtOiByZW5hbWUgcGZuX3QgdG8ga3ZtX3Bmbl90DQogICAgICAg
ICAgICAgIG1pcHM6IGZpeCBQQUdFX01BU0sgZGVmaW5pdGlvbg0KICAgICAgICAgICAgICBtbSwg
ZGF4LCBwbWVtOiBpbnRyb2R1Y2UgcGZuX3QNCiAgICAgICAgICAgICAgbW0sIGRheCwgZ3B1OiBj
b252ZXJ0IHZtX2luc2VydF9taXhlZCB0byBwZm5fdCwgaW50cm9kdWNlIF9QQUdFX0RFVk1BUA0K
ICAgICAgICAgICAgICBtbSwgZGF4OiBjb252ZXJ0IHZtZl9pbnNlcnRfcGZuX3BtZCgpIHRvIHBm
bl90DQogICAgICAgICAgICAgIGxpc3Q6IGludHJvZHVjZSBsaXN0X2RlbF9wb2lzb24oKQ0KICAg
ICAgICAgICAgICBtbSwgZGF4LCBwbWVtOiBpbnRyb2R1Y2Uge2dldHxwdXR9X2Rldl9wYWdlbWFw
KCkgZm9yIGRheC1ndXANCiAgICAgICAgICAgICAgYmxvY2s6IG5vdGlmeSBxdWV1ZSBkZWF0aCBj
b25maXJtYXRpb24NCiAgICAgICAgICAgICAgbW0sIHBtZW06IGRldm1fbWVtdW5tYXBfcGFnZXMo
KSwgdHJ1bmNhdGUgYW5kIHVubWFwIFpPTkVfREVWSUNFIHBhZ2VzDQogICAgICAgICAgICAgIG1t
LCB4ODY6IGdldF91c2VyX3BhZ2VzKCkgZm9yIGRheCBtYXBwaW5ncw0KICAgICAgICAgICAgICBi
bG9jazogaW50cm9kdWNlIGZpbGVfYmRfaW5vZGUoKQ0KICAgICAgICAgICAgICBibG9jazogZW5h
YmxlIGRheCBmb3IgcmF3IGJsb2NrIGRldmljZXMNCg0KPT09DQpmb3ItNC40L2RheC1jb3JlZHVt
cA0KPT09DQoNCiAgICAgICAgUmVjZW50bHkgYWNrZWQgYnkgSmVmZiB3aWxsIGFwcGVhciBpbiAt
bmV4dCBzaG9ydGx5Lg0KICAgICAgICANCiAgICAgICAgUm9zcyBad2lzbGVyICgyKToNCiAgICAg
ICAgICAgICAgY29yZWR1bXA6IGFkZCBEQVggZmlsdGVyaW5nIGZvciBFTEYgY29yZWR1bXBzDQog
ICAgICAgICAgICAgIGNvcmVkdW1wOiBhZGQgREFYIGZpbHRlcmluZyBmb3IgRkRQSUMgRUxGIGNv
cmVkdW1wcw0KDQo9PT0NCmZvci00LjQvbWVtcmVtYXANCmh0dHBzOi8vbHduLm5ldC9BcnRpY2xl
cy82NTM1ODUvDQo9PT0NCg0KICAgICAgICBTb21lIHBhdGNoZXMgb3V0IG9mIHRoaXMgc2VyaWVz
IGhhdmUgc3RhcnRlZCB0byBsZWFrIGludG8NCiAgICAgICAgbWFpbnRhaW5lciB0cmVlcywgYnV0
IHRoZSB1cHRha2UgaXMgZmFpcmx5IHNsb3cuICBJIG1heSBqdXN0DQogICAgICAgIHNlbmQgYSBi
cmFuY2ggdG8gTGludXMgd2l0aCB0aGUgc3RyYWdnbGVycyB0b3dhcmRzIHRoZSBlbmQgb2YNCiAg
ICAgICAgdGhlIG1lcmdlIHdpbmRvdy4NCg0KICAgICAgICBEYW4gV2lsbGlhbXMgKDIxKToNCiAg
ICAgICAgICAgICAgeDg2OiBpbnRyb2R1Y2UgYXJjaF9tZW1yZW1hcCgpDQogICAgICAgICAgICAg
IGFybTogaW50cm9kdWNlIGFyY2hfbWVtcmVtYXAoKQ0KICAgICAgICAgICAgICBpYTY0OiBpbnRy
b2R1Y2UgYXJjaF9tZW1yZW1hcCgpDQogICAgICAgICAgICAgIHNoOiBpbnRyb2R1Y2UgYXJjaF9t
ZW1yZW1hcCgpDQogICAgICAgICAgICAgIG02OGs6IGludHJvZHVjZSBhcmNoX21lbXJlbWFwKCkN
CiAgICAgICAgICAgICAgYXJtOiBzd2l0Y2ggZnJvbSBpb3JlbWFwX2NhY2hlIHRvIG1lbXJlbWFw
DQogICAgICAgICAgICAgIHg4Njogc3dpdGNoIGZyb20gaW9yZW1hcF9jYWNoZSB0byBtZW1yZW1h
cA0KICAgICAgICAgICAgICBnbWE1MDA6IHN3aXRjaCBmcm9tIGFjcGlfb3NfaW9yZW1hcCB0byBt
ZW1yZW1hcA0KICAgICAgICAgICAgICBpOTE1OiBzd2l0Y2ggZnJvbSBhY3BpX29zX2lvcmVtYXAg
dG8gbWVtcmVtYXANCiAgICAgICAgICAgICAgZHJtL3Ztd2dmeDogc3dpdGNoIGZyb20gaW9yZW1h
cF9jYWNoZSB0byBtZW1yZW1hcA0KICAgICAgICAgICAgICBhY3BpOiBzd2l0Y2ggZnJvbSBpb3Jl
bWFwX2NhY2hlIHRvIG1lbXJlbWFwDQogICAgICAgICAgICAgIHNvdW5kLCBza3lsYWtlOiBzd2l0
Y2ggZnJvbSBpb3JlbWFwX2NhY2hlIHRvIG1lbXJlbWFwDQogICAgICAgICAgICAgIG1lbWNvbnNv
bGU6IGZpeCBfX2lvbWVtIG1pc2hhbmRsaW5nLCBzd2l0Y2ggdG8gbWVtcmVtYXANCiAgICAgICAg
ICAgICAgaW50ZWwtaW9tbXU6IHN3aXRjaCBmcm9tIGlvcmVtYXBfY2FjaGUgdG8gbWVtcmVtYXAN
CiAgICAgICAgICAgICAgcHhhMnh4LWZsYXNoOiBzd2l0Y2ggZnJvbSBpb3JlbWFwX2NhY2hlIHRv
IG1lbXJlbWFwDQogICAgICAgICAgICAgIHNmaTogc3dpdGNoIGZyb20gaW9yZW1hcF9jYWNoZSB0
byBtZW1yZW1hcA0KICAgICAgICAgICAgICBmYmRldjogc3dpdGNoIGZyb20gaW9yZW1hcF93dCB0
byBtZW1yZW1hcA0KICAgICAgICAgICAgICBhcmNoOiBraWxsIGlvcmVtYXBfY2FjaGVkKCkNCiAg
ICAgICAgICAgICAgYXJjaDoga2lsbCBpb3JlbWFwX2Z1bGxjYWNoZSgpDQogICAgICAgICAgICAg
IGFyY2g6IHJlbW92ZSBpb3JlbWFwX2NhY2hlLCByZXBsYWNlIHdpdGggYXJjaF9tZW1yZW1hcA0K
ICAgICAgICAgICAgICBhcmNoOiByZW1vdmUgaW9yZW1hcF93dCwgb3B0aW9uYWxseSByZXBsYWNl
IHdpdGgNCiAgICAgICAgYXJjaF9tZW1yZW1hcA0KDQo9PT0NCmZvci00LjQvYmxrLWludGVncml0
eToNCj09PQ0KICAgICAgICANCiAgICAgICAgSmVucz8gIEkndmUgZm9sZGVkIG15IGZpeGVzIHdp
dGggTWFydGluJ3MgbGF0ZXN0IGFuZA0KICAgICAgICBibG9jay5naXQvZm9yLTQuNC9kcml2ZXJz
Lg0KICAgICAgICANCiAgICAgICAgRGFuIFdpbGxpYW1zICg3KToNCiAgICAgICAgICAgICAgbWQs
IGRtLCBzY3NpLCBudm1lLCBsaWJudmRpbW06IGRyb3AgYmxrX2ludGVncml0eV91bnJlZ2lzdGVy
KCkgYXQgc2h1dGRvd24NCiAgICAgICAgICAgICAgbWQ6IHN1c3BlbmQgaS9vIGR1cmluZyBydW50
aW1lIGJsa19pbnRlZ3JpdHlfdW5yZWdpc3Rlcg0KICAgICAgICAgICAgICBudm1lOiBzdXNwZW5k
IGkvbyBkdXJpbmcgcnVudGltZSBibGtfaW50ZWdyaXR5X3VucmVnaXN0ZXINCiAgICAgICAgICAg
ICAgYmxvY2s6IGdlbmVyaWMgcmVxdWVzdF9xdWV1ZSByZWZlcmVuY2UgY291bnRpbmcNCiAgICAg
ICAgICAgICAgYmxvY2s6IG1vdmUgYmxrX2ludGVncml0eSB0byByZXF1ZXN0X3F1ZXVlDQogICAg
ICAgICAgICAgIGJsb2NrOiBibGtfZmx1c2hfaW50ZWdyaXR5KCkgZm9yIGJpby1iYXNlZCBkcml2
ZXJzDQogICAgICAgICAgICAgIGJsb2NrLCBsaWJudmRpbW0sIG52bWU6IHByb3ZpZGUgYSBidWls
dC1pbiBibGtfaW50ZWdyaXR5IG5vcCBwcm9maWxlDQogICAgICAgIA0KICAgICAgICBNYXJ0aW4g
Sy4gUGV0ZXJzZW4gKDUpOg0KICAgICAgICAgICAgICBibG9jazogTW92ZSBpbnRlZ3JpdHkga29i
amVjdCB0byBzdHJ1Y3QgZ2VuZGlzaw0KICAgICAgICAgICAgICBibG9jazogQ29uc29saWRhdGUg
c3RhdGljIGludGVncml0eSBwcm9maWxlIHByb3BlcnRpZXMNCiAgICAgICAgICAgICAgYmxvY2s6
IFJlZHVjZSB0aGUgc2l6ZSBvZiBzdHJ1Y3QgYmxrX2ludGVncml0eQ0KICAgICAgICAgICAgICBi
bG9jazogRXhwb3J0IGludGVncml0eSBkYXRhIGludGVydmFsIHNpemUgaW4gc3lzZnMNCiAgICAg
ICAgICAgICAgYmxvY2s6IElubGluZSBibGtfaW50ZWdyaXR5IGluIHN0cnVjdCBnZW5kaXNrDQog
ICAgICAgIA0KPT09DQpmb3ItNC40L2hvdHBsdWcNCj09PQ0KDQogICAgICAgIENoYW5nZXMgcmVx
dWVzdGVkIGZvciB2MywgYnV0IG9uY2UgdGhvc2UgYXJlIGFkZHJlc3NlZCBqdXN0IG5lZWQNCiAg
ICAgICAgYW4gYWNrIGZyb20gUmFmYWVsLg0KDQogICAgICAgIFZpc2hhbCBWZXJtYSAoMik6DQog
ICAgICAgICAgICAgIG5maXQ6IGluIGFjcGlfbmZpdF9pbml0LCBicmVhayBvbiBhIDAtbGVuZ3Ro
IHRhYmxlDQogICAgICAgICAgICAgIGFjcGk6IG5maXQ6IEFkZCBzdXBwb3J0IGZvciBob3QtYWRk
DQoNCj09PQ0KZm9yLTQuNC9kb2N1bWVudGF0aW9uOg0KPT09DQoNCiAgICAgICAgSW4gLW5leHQu
Li4NCiAgICAgICAgDQogICAgICAgIEtvbnJhZCBSemVzenV0ZWsgV2lsayAoMSk6DQogICAgICAg
ICAgICAgIGxpYm52ZGltbTogZG9jdW1lbnRhdGlvbiBjbGFyaWZpY2F0aW9ucw0KICAgICAgICAN
Cg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1252385

On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
> Here is a status summary of the topic-branches nvdimm.git is tracking
> for v4.4.  Unless indicated these branches are not present in -next.
> Please ACK, NAK, or ask for a re-post of any of the below to disposition
> it for the merge window.
> 
> ===
> for-4.4/dax-fixes:
> ===
...
>         Dave Chinner (5):
>               xfs: fix inode size update overflow in xfs_map_direct()
>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
>               xfs: Don't use unwritten extents for DAX
>               xfs: DAX does not use IO completion callbacks
>               xfs: add ->pfn_mkwrite support for DAX

Please drop these. They have not been reviewed yet, and because
the changes affect more than just DAX (core XFS allocator
functionality was changed) these need to go through the XFS tree.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252394

On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
>> Here is a status summary of the topic-branches nvdimm.git is tracking
>> for v4.4.  Unless indicated these branches are not present in -next.
>> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> it for the merge window.
>>
>> ===
>> for-4.4/dax-fixes:
>> ===
> ...
>>         Dave Chinner (5):
>>               xfs: fix inode size update overflow in xfs_map_direct()
>>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
>>               xfs: Don't use unwritten extents for DAX
>>               xfs: DAX does not use IO completion callbacks
>>               xfs: add ->pfn_mkwrite support for DAX
>
> Please drop these. They have not been reviewed yet, and because
> the changes affect more than just DAX (core XFS allocator
> functionality was changed) these need to go through the XFS tree.
>

Ok, thanks for the heads up.  For the get_user_pages() patches that
build on these fixes I'm assuming your review bandwidth is in short
supply to also give an XFS sign-off on those changes for 4.4?

I'm wondering if we can take a conservative step forward with those
patches for 4.4.  if XFS and EXT4 interactions need more time to get
worked out, which I believe they do, I can conceive just turning on
get_user_pages() support for DAX-mappings of the raw block device.
This would be via the new facility I posted yesterday:
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
While not very functional for applications it makes testing base DAX
mechanisms straightforward.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252432

On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
> >> Here is a status summary of the topic-branches nvdimm.git is tracking
> >> for v4.4.  Unless indicated these branches are not present in -next.
> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
> >> it for the merge window.
> >>
> >> ===
> >> for-4.4/dax-fixes:
> >> ===
> > ...
> >>         Dave Chinner (5):
> >>               xfs: fix inode size update overflow in xfs_map_direct()
> >>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
> >>               xfs: Don't use unwritten extents for DAX
> >>               xfs: DAX does not use IO completion callbacks
> >>               xfs: add ->pfn_mkwrite support for DAX
> >
> > Please drop these. They have not been reviewed yet, and because
> > the changes affect more than just DAX (core XFS allocator
> > functionality was changed) these need to go through the XFS tree.
> >
> 
> Ok, thanks for the heads up.  For the get_user_pages() patches that
> build on these fixes I'm assuming your review bandwidth is in short
> supply to also give an XFS sign-off on those changes for 4.4?

I'm not aware of any other patches that touch XFS. AFAIA, you
haven't cc'd anything to xfs@oss.sgi.com, so it's not on my radar...

> I'm wondering if we can take a conservative step forward with those
> patches for 4.4.  if XFS and EXT4 interactions need more time to get
> worked out, which I believe they do, I can conceive just turning on
> get_user_pages() support for DAX-mappings of the raw block device.

Regardless of the ext4/XFS status, isn't it a bit late to be
proposing brand new stuff that nobody has had time to think about
for the next merge window?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252448

On Tue, Oct 20, 2015 at 7:38 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> wrote:
>> > On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
>> >> Here is a status summary of the topic-branches nvdimm.git is tracking
>> >> for v4.4.  Unless indicated these branches are not present in -next.
>> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> >> it for the merge window.
>> >>
>> >> ===
>> >> for-4.4/dax-fixes:
>> >> ===
>> > ...
>> >>         Dave Chinner (5):
>> >>               xfs: fix inode size update overflow in xfs_map_direct()
>> >>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
>> >>               xfs: Don't use unwritten extents for DAX
>> >>               xfs: DAX does not use IO completion callbacks
>> >>               xfs: add ->pfn_mkwrite support for DAX
>> >
>> > Please drop these. They have not been reviewed yet, and because
>> > the changes affect more than just DAX (core XFS allocator
>> > functionality was changed) these need to go through the XFS tree.
>> >
>>
>> Ok, thanks for the heads up.  For the get_user_pages() patches that
>> build on these fixes I'm assuming your review bandwidth is in short
>> supply to also give an XFS sign-off on those changes for 4.4?
>
> I'm not aware of any other patches that touch XFS. AFAIA, you
> haven't cc'd anything to xfs@oss.sgi.com, so it's not on my radar...
>

I can cc xfs@oss.sgi.com on fs/dax.c changes going forward, but for
these I figure it was off topic since nothing touched fs/xfs/.

>> I'm wondering if we can take a conservative step forward with those
>> patches for 4.4.  if XFS and EXT4 interactions need more time to get
>> worked out, which I believe they do, I can conceive just turning on
>> get_user_pages() support for DAX-mappings of the raw block device.
>
> Regardless of the ext4/XFS status, isn't it a bit late to be
> proposing brand new stuff that nobody has had time to think about
> for the next merge window?
>

The "dax-for-raw-block support" is indeed new, but it's a fairly
straightforward extension of these patches that have been out for
review since 4.3-rc2, or 4.1-rc6 in the case of the pfn_t enabling.
Cutting out the filesystem interactions makes it that much simpler to
comprehend.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252598

Sorry for replying to this email and not to patch posting directly but I
didn't find the original mail in any of my mailboxes...

On Tue 20-10-15 17:31:18, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
> >> Here is a status summary of the topic-branches nvdimm.git is tracking
> >> for v4.4.  Unless indicated these branches are not present in -next.
> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
> >> it for the merge window.
> >>
> >> ===
> >> for-4.4/dax-fixes:
> >> ===
> > ...
> >>         Dave Chinner (5):
> >>               xfs: fix inode size update overflow in xfs_map_direct()
> >>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
> >>               xfs: Don't use unwritten extents for DAX
> >>               xfs: DAX does not use IO completion callbacks
> >>               xfs: add ->pfn_mkwrite support for DAX
> >
> > Please drop these. They have not been reviewed yet, and because
> > the changes affect more than just DAX (core XFS allocator
> > functionality was changed) these need to go through the XFS tree.
> >
> 
> Ok, thanks for the heads up.  For the get_user_pages() patches that
> build on these fixes I'm assuming your review bandwidth is in short
> supply to also give an XFS sign-off on those changes for 4.4?
> 
> I'm wondering if we can take a conservative step forward with those
> patches for 4.4.  if XFS and EXT4 interactions need more time to get
> worked out, which I believe they do, I can conceive just turning on
> get_user_pages() support for DAX-mappings of the raw block device.
> This would be via the new facility I posted yesterday:
> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> While not very functional for applications it makes testing base DAX
> mechanisms straightforward.

I had a look at the patch and I miss one thing: Why do we need bd_mutex
to protect faults? I see a comment there:

/* check that the faulting page hasn't raced with bdev resize */

Is it really possible that bdev gets shrunk under us? Hum, looking into
fs/block_dev.c, probably it is. But there are other places - like DIO path
- assuming that block device mapping cannot just disappear from under us. I
wonder how that would cope with bdev size change...

Also we only call invalidate_bdev() to invalidate page cache pages of the
bdev after resize which specifically skips any mmaped pages so bdev resizing
in presence of mmap is unreliable to say the least.

Anyway, bd_mutex seems like a big hammer in the fast path to protect against
rare size changes. Also nesting of bd_mutex under mmap_sem makes me
somewhat uneasy (I'd definitely wonder whether lockdep would not complain
about that)...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253063

On Wed, Oct 21, 2015 at 2:08 AM, Jan Kara <jack@suse.cz> wrote:
> Sorry for replying to this email and not to patch posting directly but I
> didn't find the original mail in any of my mailboxes...

Forgive me for not including you on the initial posting.  I'll add you
to that series going forward.

> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> wrote:
>> > On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
>> >> Here is a status summary of the topic-branches nvdimm.git is tracking
>> >> for v4.4.  Unless indicated these branches are not present in -next.
>> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> >> it for the merge window.
>> >>
>> >> ===
>> >> for-4.4/dax-fixes:
>> >> ===
>> > ...
>> >>         Dave Chinner (5):
>> >>               xfs: fix inode size update overflow in xfs_map_direct()
>> >>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
>> >>               xfs: Don't use unwritten extents for DAX
>> >>               xfs: DAX does not use IO completion callbacks
>> >>               xfs: add ->pfn_mkwrite support for DAX
>> >
>> > Please drop these. They have not been reviewed yet, and because
>> > the changes affect more than just DAX (core XFS allocator
>> > functionality was changed) these need to go through the XFS tree.
>> >
>>
>> Ok, thanks for the heads up.  For the get_user_pages() patches that
>> build on these fixes I'm assuming your review bandwidth is in short
>> supply to also give an XFS sign-off on those changes for 4.4?
>>
>> I'm wondering if we can take a conservative step forward with those
>> patches for 4.4.  if XFS and EXT4 interactions need more time to get
>> worked out, which I believe they do, I can conceive just turning on
>> get_user_pages() support for DAX-mappings of the raw block device.
>> This would be via the new facility I posted yesterday:
>> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> While not very functional for applications it makes testing base DAX
>> mechanisms straightforward.
>
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults?

This is my main question for the RFC, I landed on bd_mutex as a big
hammer primarily because I don't expect more than a handful of
applications to be in a position to map a block device directly.
Aside from needing admin privileges the application must also be
satisfied with only having partitions to sub-divide the capacity.

As far as I can see, a hypervisor is the only application that is
compatible with the above constraints.  It establishes a few mappings
that exist for the lifetime of the guest and ends up with little to no
contention on an mmap lock.

> I see a comment there:
>
> /* check that the faulting page hasn't raced with bdev resize */
>
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us. I
> wonder how that would cope with bdev size change...
>
> Also we only call invalidate_bdev() to invalidate page cache pages of the
> bdev after resize which specifically skips any mmaped pages so bdev resizing
> in presence of mmap is unreliable to say the least.

True, new locking against resize just for mmap is hard to justify when
there's no protection in other paths.  Perhaps it is a case of
userspace getting to keep the pieces if it decides to race resize vs
i/o?

At least with the pmem driver there's no risk that i/o will clobber
random memory addresses past the end of the whole-disk-device since
only partitions can be resized at run time.  The base pmem device can
only be resized while offline.

> Anyway, bd_mutex seems like a big hammer in the fast path to protect against
> rare size changes. Also nesting of bd_mutex under mmap_sem makes me
> somewhat uneasy (I'd definitely wonder whether lockdep would not complain
> about that)...

Lockdep hasn't triggered to date, but I've only tried mapping the base
block device with no filesystem present.  I'll try a test that sets up
both a base device mapping and one through an fs file on the same
device.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253320

> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
> Jan Kara
> Sent: Wednesday, October 21, 2015 4:08 AM
...
> On Tue 20-10-15 17:31:18, Dan Williams wrote:
> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
...
> > I'm wondering if we can take a conservative step forward with those
> > patches for 4.4.  if XFS and EXT4 interactions need more time to get
> > worked out, which I believe they do, I can conceive just turning on
> > get_user_pages() support for DAX-mappings of the raw block device.
> > This would be via the new facility I posted yesterday:
> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> > While not very functional for applications it makes testing base DAX
> > mechanisms straightforward.
> 
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults? I see a comment there:
> 
> /* check that the faulting page hasn't raced with bdev resize */
> 
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us.
> I wonder how that would cope with bdev size change...

DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
time incrementing and decrementing i_dio_count for direct IO
to block devices, especially at pmem type speeds.  I hope 
that kind of accounting doesn't need to be brought back.

https://lkml.org/lkml/2015/4/3/557
https://lkml.org/lkml/2015/4/15/590

---
Robert Elliott, HPE Persistent Memory

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253329

On Wed, Oct 21, 2015 at 3:36 PM, Elliott, Robert (Persistent Memory)
<elliott@hpe.com> wrote:
>
>
>> -----Original Message-----
>> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
>> Jan Kara
>> Sent: Wednesday, October 21, 2015 4:08 AM
> ...
>> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
> ...
>> > I'm wondering if we can take a conservative step forward with those
>> > patches for 4.4.  if XFS and EXT4 interactions need more time to get
>> > worked out, which I believe they do, I can conceive just turning on
>> > get_user_pages() support for DAX-mappings of the raw block device.
>> > This would be via the new facility I posted yesterday:
>> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> > While not very functional for applications it makes testing base DAX
>> > mechanisms straightforward.
>>
>> I had a look at the patch and I miss one thing: Why do we need bd_mutex
>> to protect faults? I see a comment there:
>>
>> /* check that the faulting page hasn't raced with bdev resize */
>>
>> Is it really possible that bdev gets shrunk under us? Hum, looking into
>> fs/block_dev.c, probably it is. But there are other places - like DIO path
>> - assuming that block device mapping cannot just disappear from under us.
>> I wonder how that would cope with bdev size change...
>
> DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
> time incrementing and decrementing i_dio_count for direct IO
> to block devices, especially at pmem type speeds.  I hope
> that kind of accounting doesn't need to be brought back.
>
> https://lkml.org/lkml/2015/4/3/557
> https://lkml.org/lkml/2015/4/15/590

Thanks for that reminder Robert.  I think this backs up my suspicion
that the base mmap_sem protections should be enough for raw block mmap
+ DAX.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253093

On 10/20/2015 05:31 PM, Williams, Dan J wrote:
> ===
> for-4.4/dax-gup: get_user_pages() support for dax mappings
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_linux-2Dnvdimm_2015-2DOctober_002387.html&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=GDROuamLFa0boM8dkPE6fXkQ-bqUhy3M3gH-W-7UaUU&s=S8I_OUhMMB7AAcJn6TzV01M9jB6e2wB3aMIT4lTGHf8&e=
> ===
>
>          Needs acks from core -mm folks particularly for:
>                  x86, mm: introduce vmem_altmap to augment
>                  vmemmap_populate()
>                  mm, x86: get_user_pages() for dax mappings
>
>          Dan Williams (22):
>                block: generic request_queue reference counting
>                dax: increase granularity of dax_clear_blocks() operations
>                block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()
>                mm: introduce __get_dev_pagemap()
>                x86, mm: introduce vmem_altmap to augment vmemmap_populate()
>                libnvdimm, pfn, pmem: allocate memmap array in persistent memory
>                avr32: convert to asm-generic/memory_model.h
>                hugetlb: fix compile error on tile
>                frv: fix compiler warning from definition of __pmd()
>                um: kill pfn_t
>                kvm: rename pfn_t to kvm_pfn_t
>                mips: fix PAGE_MASK definition
>                mm, dax, pmem: introduce pfn_t
>                mm, dax, gpu: convert vm_insert_mixed to pfn_t, introduce _PAGE_DEVMAP
>                mm, dax: convert vmf_insert_pfn_pmd() to pfn_t
>                list: introduce list_del_poison()
>                mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
>                block: notify queue death confirmation
>                mm, pmem: devm_memunmap_pages(), truncate and unmap ZONE_DEVICE pages
>                mm, x86: get_user_pages() for dax mappings
>                block: introduce file_bd_inode()
>                block: enable dax for raw block devices

We really should pull these core block changes in separately.

> ===
> for-4.4/blk-integrity:
> ===
>
>          Jens?  I've folded my fixes with Martin's latest and
>          block.git/for-4.4/drivers.
>
>          Dan Williams (7):
>                md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
>                md: suspend i/o during runtime blk_integrity_unregister
>                nvme: suspend i/o during runtime blk_integrity_unregister
>                block: generic request_queue reference counting
>                block: move blk_integrity to request_queue
>                block: blk_flush_integrity() for bio-based drivers
>                block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
>
>          Martin K. Petersen (5):
>                block: Move integrity kobject to struct gendisk
>                block: Consolidate static integrity profile properties
>                block: Reduce the size of struct blk_integrity
>                block: Export integrity data interval size in sysfs
>                block: Inline blk_integrity in struct gendisk

I'll pull these in.


-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253311

On Wed, Oct 21, 2015 at 10:47 AM, Jens Axboe <axboe@fb.com> wrote:
> On 10/20/2015 05:31 PM, Williams, Dan J wrote:
>>
>> ===
>> for-4.4/dax-gup: get_user_pages() support for dax mappings
[..]
>> ===
[..]
> We really should pull these core block changes in separately.

Sounds good to me.  I'll refactor the block bits into a standalone series.

>> ===
>> for-4.4/blk-integrity:
>> ===
[..]
>
>
> I'll pull these in.
>

Much appreciated!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253301

On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
> Here is a status summary of the topic-branches nvdimm.git is tracking
> for v4.4.  Unless indicated these branches are not present in -next.
> Please ACK, NAK, or ask for a re-post of any of the below to disposition
> it for the merge window.
> 
> ===
> for-4.4/dax-fixes:
> ===
<snip>
>         Ross Zwisler (2):
>               dax: dax_pfn_mkwrite() truncate race check

We can drop this patch for dax_pfn_mkwrite() as that whole function is going
away after we merge the locking fixes from XFS, ext2 and ext4.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web