* [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-10 16:47 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-10 16:47 UTC (permalink / raw) To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org SGkgTGludXMsDQoNClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBjb21taXQgNGY3ZDAyOWI5 YmYwMDlmYmVlNzZiYjEwYzBjNDM1MWExODcwZDJmMzoNCg0KICBMaW51eCA0LjExLXJjNyAoMjAx Ny0wNC0xNiAxMzowMDoxOCAtMDcwMCkNCg0KYXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9z aXRvcnkgYXQ6DQoNCiAgZ2l0Oi8vZ2l0LmxpbnV4LW5mcy5vcmcvcHJvamVjdHMvdHJvbmRteS9s aW51eC1uZnMuZ2l0IHRhZ3MvbmZzLWZvci00LjEyLTENCg0KZm9yIHlvdSB0byBmZXRjaCBjaGFu Z2VzIHVwIHRvIDc2YjJhMzAzMzg0ZTFkNjI5OWMzYTAyNDlmMGYwY2UyZjhmOTYwMTc6DQoNCiAg cE5GUy9mbGV4ZmlsZXM6IEFsd2F5cyBhdHRlbXB0IHRvIGNhbGwgbGF5b3V0c3RhdHMgd2hlbiBm bGV4ZmlsZXMgaXMgZW5hYmxlZCAoMjAxNy0wNS0wOSAxNjowMjo1NyAtMDQwMCkNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KTkZTIGNsaWVudCB1cGRhdGVzIGZvciBMaW51eCA0LjEyDQoNCkhpZ2hsaWdodHMgaW5jbHVk ZToNCg0KU3RhYmxlIGJ1Z2ZpeGVzOg0KLSBGaXggdXNlIGFmdGVyIGZyZWUgaW4gd3JpdGUgZXJy b3IgcGF0aA0KLSBVc2UgR0ZQX05PSU8gZm9yIHR3byBhbGxvY2F0aW9ucyBpbiB3cml0ZWJhY2sN Ci0gRml4IGEgaGFuZyBpbiBPUEVOIHJlbGF0ZWQgdG8gc2VydmVyIHJlYm9vdA0KLSBDaGVjayB0 aGUgcmVzdWx0IG9mIG5mczRfcG5mc19kc19jb25uZWN0DQotIEZpeCBhbiByY3UgbG9jayBsZWFr DQoNCkZlYXR1cmVzOg0KLSBSZW1vdmFsIG9mIHRoZSB1bm1haW50YWluZWQgYW5kIHVudXNlZCBP U0QgcE5GUyBsYXlvdXQNCi0gQ2xlYW51cCBhbmQgcmVtb3ZhbCBvZiBsb3RzIG9mIHVubmVjZXNz YXJ5IGRwcmludGsoKXMNCi0gQ2xlYW51cCBhbmQgcmVtb3ZhbCBvZiBzb21lIG1lbW9yeSBmYWls dXJlIHBhdGhzIG5vdyB0aGF0DQogIEdGUF9OT0ZTIGlzIGd1YXJhbnRlZWQgdG8gbmV2ZXIgZmFp bC4NCi0gUmVtb3ZlIHRoZSB2My1vbmx5IGRhdGEgc2VydmVyIGxpbWl0YXRpb24gb24gcE5GUy9m bGV4ZmlsZXMNCg0KQnVnZml4ZXM6DQotIFJQQy9SRE1BIGNvbm5lY3Rpb24gaGFuZGxpbmcgYnVn Zml4ZXMNCi0gQ29weSBvZmZsb2FkOiBmaXhlcyB0byBlbnN1cmUgdGhlIGNvcGllZCBkYXRhIGlz IENPTU1JVGVkIHRvIGRpc2suDQotIFJlYWRkaXI6IHN3aXRjaCBiYWNrIHRvIHVzaW5nIHRoZSAt Pml0ZXJhdGUgVkZTIGludGVyZmFjZQ0KLSBGaWxlIGxvY2tpbmcgZml4ZXMgZnJvbSBCZW4gQ29k ZGluZ3Rvbg0KLSBWYXJpb3VzIHVzZS1hZnRlci1mcmVlIGFuZCBkZWFkbG9jayBpc3N1ZXMgaW4g cE5GUw0KLSBXcml0ZSBwYXRoIGJ1Z2ZpeGVzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFubmEgU2NodW1ha2VyICgy OSk6DQogICAgICBORlM6IENsZWFuIHVwIGRvX2NhbGxiYWNrX2xheW91dHJlY2FsbCgpDQogICAg ICBORlM6IENsZWFuIHVwIG5mczRfY2FsbGJhY2tfbGF5b3V0cmVjYWxsKCkNCiAgICAgIE5GUzog UmVtb3ZlIGV4dHJhIGRwcmludGsoKXMgZnJvbSBjYWxsYmFja19wcm9jLmMNCiAgICAgIE5GUzog Q2xlYW4gdXAgZGVjb2RlX2dldGF0dHJfYXJncygpDQogICAgICBORlM6IENsZWFuIHVwIGRlY29k ZV9yZWNhbGxfYXJncygpDQogICAgICBORlM6IENsZWFuIHVwIGRlY29kZV9sYXlvdXRyZWNhbGxf YXJncygpDQogICAgICBORlM6IENsZWFuIHVwIGRlY29kZV9jYl9zZXF1ZW5jZV9hcmdzKCkNCiAg ICAgIE5GUzogQ2xlYW4gdXAgZGVjb2RlX25vdGlmeV9sb2NrX2FyZ3MoKQ0KICAgICAgTkZTOiBD bGVhbiB1cCBlbmNvZGVfY2Jfc2VxdWVuY2VfcmVzKCkNCiAgICAgIE5GUzogUmVtb3ZlIGV4dHJh IGRwcmludGsoKXMgZnJvbSBjYWxsYmFja194ZHIuYw0KICAgICAgTkZTOiBDbGVhbiB1cCBuZnNf aW5pdF9jbGllbnQoKQ0KICAgICAgTkZTOiBDbGVhbiB1cCBleHRyYSBkcHJpbnRrKClzIGluIGNs aWVudC5jDQogICAgICBORlM6IFJlbW92ZSBuZnNfZGlyZWN0X3JlYWRwYWdlX3JlbGVhc2UoKQ0K ICAgICAgTkZTOiBDbGVhbiB1cCBuZnNfZGlyZWN0X2NvbW1pdF9jb21wbGV0ZSgpDQogICAgICBO RlM6IFJlbW92ZSBleHRyYSBkcHJpbnRrKClzIGZyb20gbmFtZXNwYWNlLmMNCiAgICAgIE5GUzog Q2xlYW4gdXAgbmZzNDJfbGF5b3V0c3RhdF9kb25lKCkNCiAgICAgIE5GUzogQ2xlYW4gdXAgbmZz NF9tYXRjaF9jbGllbnRpZHMoKQ0KICAgICAgTkZTOiBDbGVhbiB1cCBuZnM0X2NoZWNrX3NlcnZl cm93bmVyX21pbm9yX2lkKCkNCiAgICAgIE5GUzogQ3JlYXRlIGEgY29tbW9uIG5mczRfbWF0Y2hf Y2xpZW50KCkgZnVuY3Rpb24NCiAgICAgIE5GUzogQ2xlYW4gdXAgbmZzNF9jaGVja19zZXJ2ZXJv d25lcl9tYWpvcl9pZCgpDQogICAgICBORlM6IENsZWFuIHVwIG5mczRfY2hlY2tfc2VydmVyX3Nj b3BlKCkNCiAgICAgIE5GUzogQ2xlYW4gdXAgbmZzNF9zZXRfY2xpZW50KCkNCiAgICAgIE5GUzog Q2xlYW4gdXAgbmZzNF9pbml0X3NlcnZlcigpDQogICAgICBORlM6IFJlbW92ZSBleHRyYSBkcHJp bnRrKClzIGZyb20gbmZzNGNsaWVudC5jDQogICAgICBORlM6IENsZWFuIHVwIG5mczRfZ2V0X3Jv b3RmaCgpDQogICAgICBORlM6IFJlbW92ZSBleHRyYSBkcHJpbnRrKClzIGZyb20gbmZzNG5hbWVz cGFjZS5jDQogICAgICBORlM6IENsZWFuIHVwIG5mczRfcHJvY19iaW5kX29uZV9jb25uX3RvX3Nl c3Npb24oKQ0KICAgICAgTkZTOiBDbGVhbiB1cCBfbmZzNF9wcm9jX2V4Y2hhbmdlX2lkKCkNCiAg ICAgIE5GUzogQ2xlYW4gdXAgbmZzNF9wcm9jX2dldF9sZWFzZV90aW1lKCkNCg0KQXJ0ZW0gU2F2 a292ICgxKToNCiAgICAgIG5mcy9maWxlbGF5b3V0OiBmaXggTlVMTCBwb2ludGVyIGRlcmVmZXJl bmNlIGluIGZsX3BuZnNfdXBkYXRlX2xheW91dCgpDQoNCkJlbmphbWluIENvZGRpbmd0b24gKDEx KToNCiAgICAgIE5GUzogc3dpdGNoIGJhY2sgdG8gdG8gLT5pdGVyYXRlKCkNCiAgICAgIE5GUzog Rml4IG1pc3NpbmcgcGdfY2xlYW51cCBhZnRlciBuZnNfcGFnZWlvX2NvbmRfY29tcGxldGUoKQ0K ICAgICAgTkZTOiBVc2UgR0ZQX05PSU8gZm9yIHR3byBhbGxvY2F0aW9ucyBpbiB3cml0ZWJhY2sN CiAgICAgIE5GUzogbW92ZSBuZnNfcGdhcnJheV9zZXQoKSB0byBvcGVuIGNvZGUNCiAgICAgIE5G UzogbW92ZSByd19tb2RlIHRvIG5mc19wYWdlaW9faGVhZGVyDQogICAgICBORlM0OiByZW1vdmUg YSByZWR1bmRhbnQgbG9jayByYW5nZSBjaGVjaw0KICAgICAgTkZTOiBNb3ZlIHRoZSBmbG9jayBv cGVuIG1vZGUgY2hlY2sgaW50byBuZnNfZmxvY2soKQ0KICAgICAgbG9ja3M6IFNldCBGTF9DTE9T RSB3aGVuIHJlbW92aW5nIGZsb2NrIGxvY2tzIG9uIGNsb3NlKCkNCiAgICAgIE5GUzogQWRkIGFu IGlvY291bnRlciB3YWl0IGZ1bmN0aW9uIGZvciBhc3luYyBSUEMgdGFza3MNCiAgICAgIGxvY2tk OiBJbnRyb2R1Y2UgbmxtY2xudF9vcGVyYXRpb25zDQogICAgICBORlM6IEFsd2F5cyB3YWl0IGZv ciBJL08gY29tcGxldGlvbiBiZWZvcmUgdW5sb2NrDQoNCkNocmlzdG9waCBIZWxsd2lnICgxKToN CiAgICAgIG5mczogcmVtb3ZlIHRoZSBvYmpsYXlvdXQgZHJpdmVyDQoNCkNodWNrIExldmVyICgx Myk6DQogICAgICB4cHJ0cmRtYTogQ2FuY2VsIHJlZnJlc2ggd29ya2VyIGR1cmluZyBidWZmZXIg c2h1dGRvd24NCiAgICAgIHN1bnJwYzogRXhwb3J0IHhwcnRfZm9yY2VfZGlzY29ubmVjdCgpDQog ICAgICB4cHJ0cmRtYTogRGV0ZWN0IHVucmVhY2hhYmxlIE5GUy9SRE1BIHNlcnZlcnMgbW9yZSBy ZWxpYWJseQ0KICAgICAgeHBydHJkbWE6IFJlZmFjdG9yIHJwY3JkbWFfaWFfb3BlbigpDQogICAg ICB4cHJ0cmRtYTogVXNlIHNhbWUgZGV2aWNlIHdoZW4gbWFwcGluZyBvciBzeW5jaW5nIERNQSBi dWZmZXJzDQogICAgICB4cHJ0cmRtYTogU3VwcG9ydCB1bnBsdWdnaW5nIGFuIEhDQSBmcm9tIHVu ZGVyIGFuIE5GUyBtb3VudA0KICAgICAgeHBydHJkbWE6IFJlZmFjdG9yIHJwY3JkbWFfZXBfY29u bmVjdA0KICAgICAgeHBydHJkbWE6IFJlc3RvcmUgdHJhbnNwb3J0IGFmdGVyIGRldmljZSByZW1v dmFsDQogICAgICB4cHJ0cmRtYTogUmV2ZXJ0IGNvbW1pdCBkMGYzNmM0NmRlZWENCiAgICAgIHhw cnRyZG1hOiBBbm5vdGF0ZSByZWNlaXZlIHdvcmtxdWV1ZQ0KICAgICAgeHBydHJkbWE6IFNxdWVs Y2ggRU5PQlVGUyB3YXJuaW5ncw0KICAgICAgc3VucnBjOiBGaXggeGRyX2luaXRfZGVjb2RlX3Bh Z2VzKCkgZG9jdW1lbnRpbmcgY29tbWVudA0KICAgICAgeHBydHJkbWE6IFJlbW92ZSBycGNyZG1h X2J1ZmZlcjo6cmJfcG9vbA0KDQpEYXZlIFd5c29jaGFuc2tpICgxKToNCiAgICAgIEZpeCBuZnNf Y2xpZW50IHJlZmNvdW50aW5nIGlmIGttYWxsb2MgZmFpbHMgaW4gbmZzNF9wcm9jX2V4Y2hhbmdl X2lkIGFuZCBuZnM0X3Byb2NfYXN5bmNfcmVuZXcNCg0KRmFiaWFuIEZyZWRlcmljayAoMSk6DQog ICAgICBuZnM6IHVzZSBrbWFwL2t1bm1hcCBkaXJlY3RseQ0KDQpGcmVkIElzYW1hbiAoMik6DQog ICAgICBORlM6IEZpeCB1c2UgYWZ0ZXIgZnJlZSBpbiB3cml0ZSBlcnJvciBwYXRoDQogICAgICBw TkZTOiBGaXggTlVMTCBkZXJlZmVyZW5jZSBpbiBwbmZzX2dlbmVyaWNfYWxsb2NfZHNfY29tbWl0 cw0KDQpIb3UgVGFvICgxKToNCiAgICAgIE5GUzogYWx3YXlzIHRyZWF0IHRoZSBpbnZvY2F0aW9u IG9mIG5mc19nZXRhdHRyIGFzIGNhY2hlIGhpdCB3aGVuIG5vYWMgaXMgb24NCg0KTmVpbEJyb3du ICgyKToNCiAgICAgIE5GUzogZml4IHVzYWdlIG9mIG1lbXBvb2xzLg0KICAgICAgc3VucnBjOiBk b24ndCBjaGVjayBmb3IgZmFpbHVyZSBmcm9tIG1lbXBvb2xfYWxsb2MoKQ0KDQpPbGdhIEtvcm5p ZXZza2FpYSAoMik6DQogICAgICBORlM0LjEgaGFuZGxlIGludGVycnVwdGVkIHNsb3QgcmV1c2Ug ZnJvbSBFUlJfREVMQVkNCiAgICAgIE5GUyBhcHBlbmQgQ09NTUlUIGFmdGVyIHN5bmNocm9ub3Vz IENPUFkNCg0KUGFuIEJpYW4gKDEpOg0KICAgICAgTkZTdjQ6IGNoZWNrIHJldHVybiB2YWx1ZSBv ZiB4ZHJfaW5saW5lX2RlY29kZQ0KDQpUaWdyYW4gTWtydGNoeWFuICgxKToNCiAgICAgIG5mczog ZmxleGZpbGVsYXlvdXQ6IHJlbW92ZSB2My1vbmx5IGRhdGEgc2VydmVyIGxpbWl0YXRpb24NCg0K VHJvbmQgTXlrbGVidXN0ICgyNCk6DQogICAgICBORlN2NDogRml4IGEgaGFuZyBpbiBPUEVOIHJl bGF0ZWQgdG8gc2VydmVyIHJlYm9vdA0KICAgICAgcE5GUy9mbGV4ZmlsZXM6IENoZWNrIHRoZSBy ZXN1bHQgb2YgbmZzNF9wbmZzX2RzX2Nvbm5lY3QNCiAgICAgIHBORlM6IFJlbW92ZSB1bnVzZWQg bGF5b3V0IGRyaXZlciBjYWxsYmFja3MNCiAgICAgIHBORlM6IFVuZXhwb3J0IHBuZnNfcHV0X2xz ZWdfbG9ja2VkIGFuZCBfcG5mc19yZXR1cm5fbGF5b3V0DQogICAgICBwTkZTOiB1bmV4cG9ydCBu ZnM0X3BuZnNfdjNfZHNfY29ubmVjdF91bmxvYWQNCiAgICAgIHBORlM6IEVuc3VyZSB3ZSBjaGVj ayBsYXlvdXQgc2VnbWVudCB2YWxpZGl0eSBpbiB0aGUgcGdfaW5pdCgpIGNhbGxiYWNrDQogICAg ICBwTkZTOiBGaXggdXNlIGFmdGVyIGZyZWUgaXNzdWVzIGluIHBuZnNfZG9fcmVhZCgpDQogICAg ICBORlM6IERvbid0IHdyaXRlIGJhY2sgZnVydGhlciByZXF1ZXN0cyBpZiB0aGVyZSBpcyBhIHBl bmRpbmcgd3JpdGUgZXJyb3INCiAgICAgIE5GU3YzOiBuZnMzX25sbV9hbGxvY19jYWxsIHNob3Vs ZCBiZSBkZWNsYXJlZCBzdGF0aWMNCiAgICAgIE1lcmdlIHRhZyAnbmZzLXJkbWEtNC4xMi0xJyBv ZiBnaXQ6Ly9naXQubGludXgtbmZzLm9yZy9wcm9qZWN0cy9hbm5hL25mcy1yZG1hDQogICAgICBO RlM6IEFkZCBhIGZldyBtb3JlIGZhdGFsIEkvTyBlcnJvcnMgdG8gbmZzX2Vycm9yX2lzX2ZhdGFs KCkNCiAgICAgIE5GU3Y0OiBEb24ndCBzcGVjaWFsIGNhc2UgImxhdW5kZXIiDQogICAgICBwTkZT OiBFbnN1cmUgd2UgY2hlY2sgbGF5b3V0IHZhbGlkaXR5IGJlZm9yZSBtYXJraW5nIGl0IGZvciBy ZXR1cm4NCiAgICAgIHBORlMvZmxleGZpbGVzOiBGaXggdXAgdGhlIGZmX2xheW91dF93cml0ZV9w YWdlbGlzdCBmYWlsdXJlIHBhdGgNCiAgICAgIHBORlM6IERvbid0IHNlbmQgQ09NTUlUcyB0byB0 aGUgRFNlcyBpZiB0aGUgc2VydmVyIGludmFsaWRhdGVkIG91ciBsYXlvdXQNCiAgICAgIHBORlM6 IEVuc3VyZSB3ZSBjb21taXQgdGhlIGxheW91dCBpZiBpdCBoYXMgYmVlbiBpbnZhbGlkYXRlZA0K ICAgICAgcE5GUzogRG9uJ3QgY2xlYXIgdGhlIGxheW91dCByZXR1cm4gaW5mbyBpZiB0aGVyZSBh cmUgc2VnbWVudHMgdG8gcmV0dXJuDQogICAgICBwTkZTOiBGaXggYSBkZWFkbG9jayB3aGVuIGNv YWxlc2Npbmcgd3JpdGVzIGFuZCByZXR1cm5pbmcgdGhlIGxheW91dA0KICAgICAgcE5GUzogRml4 IGEgdHlwbyBpbiBwbmZzX2dlbmVyaWNfYWxsb2NfZHNfY29tbWl0cw0KICAgICAgTkZTdjQuMTog UkVDTEFJTV9DT01QTEVURSBtdXN0IGhhbmRsZSBORlM0RVJSX0NPTk5fTk9UX0JPVU5EX1RPX1NF U1NJT04NCiAgICAgIE5GU3Y0OiBGaXggYW4gcmN1IGxvY2sgbGVhaw0KICAgICAgTkZTdjQ6IEZp eCBleGNsdXNpdmUgY3JlYXRlIGF0dHJpYnV0ZXMgZW5jb2RpbmcNCiAgICAgIE5GU3Y0LjE6IFdv cmsgYXJvdW5kIGEgTGludXggc2VydmVyIGJ1Zy4uLg0KICAgICAgcE5GUy9mbGV4ZmlsZXM6IEFs d2F5cyBhdHRlbXB0IHRvIGNhbGwgbGF5b3V0c3RhdHMgd2hlbiBmbGV4ZmlsZXMgaXMgZW5hYmxl ZA0KDQogRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9rZXJuZWwtcGFyYW1ldGVycy50eHQgfCAg IDYgLQ0KIERvY3VtZW50YXRpb24vZmlsZXN5c3RlbXMvbmZzL3BuZnMudHh0ICAgICAgICAgIHwg IDM3IC0tDQogZnMvZnVzZS9maWxlLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIDIgKy0NCiBmcy9sb2NrZC9jbG50bG9jay5jICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgMSArDQogZnMvbG9ja2QvY2xudHByb2MuYyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgMjYgKy0NCiBmcy9sb2Nrcy5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgMiArLQ0KIGZzL25mcy9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICA1IC0NCiBmcy9uZnMvTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgMSAtDQogZnMvbmZzL2NhbGxiYWNrX3Byb2MuYyAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgNDcgKy0NCiBmcy9uZnMvY2FsbGJhY2tfeGRyLmMgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IDEwOSArLS0tDQogZnMvbmZzL2NsaWVudC5jICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgNjcgKy0tDQogZnMvbmZzL2Rpci5jICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAxMDQgKy0tLQ0KIGZzL25mcy9kaXJlY3QuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIDIxICstDQogZnMvbmZzL2ZpbGUuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgMzAgKy0NCiBmcy9uZnMvZmlsZWxheW91dC9maWxl bGF5b3V0LmMgICAgICAgICAgICAgICAgICB8ICAgOCArLQ0KIGZzL25mcy9mbGV4ZmlsZWxheW91 dC9mbGV4ZmlsZWxheW91dC5jICAgICAgICAgIHwgIDI0ICstDQogZnMvbmZzL2ZsZXhmaWxlbGF5 b3V0L2ZsZXhmaWxlbGF5b3V0ZGV2LmMgICAgICAgfCAgMTAgKy0NCiBmcy9uZnMvaW5vZGUuYyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNSArLQ0KIGZzL25mcy9pbnRlcm5h bC5oICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA1ICstDQogZnMvbmZzL25hbWVz cGFjZS5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMzQgKy0NCiBmcy9uZnMvbmZz M3Byb2MuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICA1NCArLQ0KIGZzL25mcy9u ZnM0MnByb2MuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDI0ICstDQogZnMvbmZz L25mczQyeGRyLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMjIgKy0NCiBmcy9u ZnMvbmZzNGNsaWVudC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDI4MyArKystLS0t LS0tDQogZnMvbmZzL25mczRnZXRyb290LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg IDMgLQ0KIGZzL25mcy9uZnM0bmFtZXNwYWNlLmMgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICA3ICstDQogZnMvbmZzL25mczRwcm9jLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgOTkgKystLQ0KIGZzL25mcy9uZnM0c3RhdGUuYyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIDEwICstDQogZnMvbmZzL25mczR4ZHIuYyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgOTQgKystLQ0KIGZzL25mcy9vYmpsYXlvdXQvS2J1aWxkICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICA1IC0NCiBmcy9uZnMvb2JqbGF5b3V0L29iamlvX29zZC5jICAgICAgICAg ICAgICAgICAgICB8IDY3NSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogZnMvbmZzL29iamxheW91 dC9vYmpsYXlvdXQuYyAgICAgICAgICAgICAgICAgICAgfCA3MDYgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogZnMvbmZzL29iamxheW91dC9vYmpsYXlvdXQuaCAgICAgICAgICAgICAgICAgICAg fCAxODMgLS0tLS0tDQogZnMvbmZzL29iamxheW91dC9wbmZzX29zZF94ZHJfY2xpLmMgICAgICAg ICAgICAgfCA0MTUgLS0tLS0tLS0tLS0tLS0NCiBmcy9uZnMvcGFnZWxpc3QuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICA3NyArKy0NCiBmcy9uZnMvcG5mcy5jICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICA2MiArKy0NCiBmcy9uZnMvcG5mcy5oICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNiArLQ0KIGZzL25mcy9wbmZzX25mcy5jICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDI0ICstDQogZnMvbmZzL3Byb2MuYyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKy0NCiBmcy9uZnMvcmVhZC5jICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgOSArLQ0KIGZzL25mcy93cml0ZS5j ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgMTIxICsrLS0NCiBpbmNsdWRlL2xp bnV4L2ZzLmggICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQogaW5jbHVkZS9s aW51eC9sb2NrZC9iaW5kLmggICAgICAgICAgICAgICAgICAgICAgfCAgMjQgKy0NCiBpbmNsdWRl L2xpbnV4L2xvY2tkL2xvY2tkLmggICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQogaW5jbHVk ZS9saW51eC9uZnNfZnMuaCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMTcgKy0NCiBpbmNs dWRlL2xpbnV4L25mc19mc19zYi5oICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQogaW5j bHVkZS9saW51eC9uZnNfcGFnZS5oICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDUgKy0NCiBp bmNsdWRlL2xpbnV4L25mc194ZHIuaCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMyArDQog bmV0L3N1bnJwYy9jbG50LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDggLQ0K IG5ldC9zdW5ycGMvc2NoZWQuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA1IC0N CiBuZXQvc3VucnBjL3hkci5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiAr LQ0KIG5ldC9zdW5ycGMveHBydC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAx ICsNCiBuZXQvc3VucnBjL3hwcnRyZG1hL3JwY19yZG1hLmMgICAgICAgICAgICAgICAgICB8ICAx MiArLQ0KIG5ldC9zdW5ycGMveHBydHJkbWEvdHJhbnNwb3J0LmMgICAgICAgICAgICAgICAgIHwg IDU3ICstDQogbmV0L3N1bnJwYy94cHJ0cmRtYS92ZXJicy5jICAgICAgICAgICAgICAgICAgICAg fCAzMjMgKysrKysrKy0tLS0NCiBuZXQvc3VucnBjL3hwcnRyZG1hL3hwcnRfcmRtYS5oICAgICAg ICAgICAgICAgICB8ICAyMiArLQ0KIDU2IGZpbGVzIGNoYW5nZWQsIDk0OSBpbnNlcnRpb25zKCsp LCAyOTYwIGRlbGV0aW9ucygtKQ0KIGRlbGV0ZSBtb2RlIDEwMDY0NCBmcy9uZnMvb2JqbGF5b3V0 L0tidWlsZA0KIGRlbGV0ZSBtb2RlIDEwMDY0NCBmcy9uZnMvb2JqbGF5b3V0L29iamlvX29zZC5j DQogZGVsZXRlIG1vZGUgMTAwNjQ0IGZzL25mcy9vYmpsYXlvdXQvb2JqbGF5b3V0LmMNCiBkZWxl dGUgbW9kZSAxMDA2NDQgZnMvbmZzL29iamxheW91dC9vYmpsYXlvdXQuaA0KIGRlbGV0ZSBtb2Rl IDEwMDY0NCBmcy9uZnMvb2JqbGF5b3V0L3BuZnNfb3NkX3hkcl9jbGkuYw0KLS0gDQpUcm9uZCBN eWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25k Lm15a2xlYnVzdEBwcmltYXJ5ZGF0YS5jb20NCg== ^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-10 16:47 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-10 16:47 UTC (permalink / raw) To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org Hi Linus, The following changes since commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3: Linux 4.11-rc7 (2017-04-16 13:00:18 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.12-1 for you to fetch changes up to 76b2a303384e1d6299c3a0249f0f0ce2f8f96017: pNFS/flexfiles: Always attempt to call layoutstats when flexfiles is enabled (2017-05-09 16:02:57 -0400) ---------------------------------------------------------------- NFS client updates for Linux 4.12 Highlights include: Stable bugfixes: - Fix use after free in write error path - Use GFP_NOIO for two allocations in writeback - Fix a hang in OPEN related to server reboot - Check the result of nfs4_pnfs_ds_connect - Fix an rcu lock leak Features: - Removal of the unmaintained and unused OSD pNFS layout - Cleanup and removal of lots of unnecessary dprintk()s - Cleanup and removal of some memory failure paths now that GFP_NOFS is guaranteed to never fail. - Remove the v3-only data server limitation on pNFS/flexfiles Bugfixes: - RPC/RDMA connection handling bugfixes - Copy offload: fixes to ensure the copied data is COMMITed to disk. - Readdir: switch back to using the ->iterate VFS interface - File locking fixes from Ben Coddington - Various use-after-free and deadlock issues in pNFS - Write path bugfixes ---------------------------------------------------------------- Anna Schumaker (29): NFS: Clean up do_callback_layoutrecall() NFS: Clean up nfs4_callback_layoutrecall() NFS: Remove extra dprintk()s from callback_proc.c NFS: Clean up decode_getattr_args() NFS: Clean up decode_recall_args() NFS: Clean up decode_layoutrecall_args() NFS: Clean up decode_cb_sequence_args() NFS: Clean up decode_notify_lock_args() NFS: Clean up encode_cb_sequence_res() NFS: Remove extra dprintk()s from callback_xdr.c NFS: Clean up nfs_init_client() NFS: Clean up extra dprintk()s in client.c NFS: Remove nfs_direct_readpage_release() NFS: Clean up nfs_direct_commit_complete() NFS: Remove extra dprintk()s from namespace.c NFS: Clean up nfs42_layoutstat_done() NFS: Clean up nfs4_match_clientids() NFS: Clean up nfs4_check_serverowner_minor_id() NFS: Create a common nfs4_match_client() function NFS: Clean up nfs4_check_serverowner_major_id() NFS: Clean up nfs4_check_server_scope() NFS: Clean up nfs4_set_client() NFS: Clean up nfs4_init_server() NFS: Remove extra dprintk()s from nfs4client.c NFS: Clean up nfs4_get_rootfh() NFS: Remove extra dprintk()s from nfs4namespace.c NFS: Clean up nfs4_proc_bind_one_conn_to_session() NFS: Clean up _nfs4_proc_exchange_id() NFS: Clean up nfs4_proc_get_lease_time() Artem Savkov (1): nfs/filelayout: fix NULL pointer dereference in fl_pnfs_update_layout() Benjamin Coddington (11): NFS: switch back to to ->iterate() NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete() NFS: Use GFP_NOIO for two allocations in writeback NFS: move nfs_pgarray_set() to open code NFS: move rw_mode to nfs_pageio_header NFS4: remove a redundant lock range check NFS: Move the flock open mode check into nfs_flock() locks: Set FL_CLOSE when removing flock locks on close() NFS: Add an iocounter wait function for async RPC tasks lockd: Introduce nlmclnt_operations NFS: Always wait for I/O completion before unlock Christoph Hellwig (1): nfs: remove the objlayout driver Chuck Lever (13): xprtrdma: Cancel refresh worker during buffer shutdown sunrpc: Export xprt_force_disconnect() xprtrdma: Detect unreachable NFS/RDMA servers more reliably xprtrdma: Refactor rpcrdma_ia_open() xprtrdma: Use same device when mapping or syncing DMA buffers xprtrdma: Support unplugging an HCA from under an NFS mount xprtrdma: Refactor rpcrdma_ep_connect xprtrdma: Restore transport after device removal xprtrdma: Revert commit d0f36c46deea xprtrdma: Annotate receive workqueue xprtrdma: Squelch ENOBUFS warnings sunrpc: Fix xdr_init_decode_pages() documenting comment xprtrdma: Remove rpcrdma_buffer::rb_pool Dave Wysochanski (1): Fix nfs_client refcounting if kmalloc fails in nfs4_proc_exchange_id and nfs4_proc_async_renew Fabian Frederick (1): nfs: use kmap/kunmap directly Fred Isaman (2): NFS: Fix use after free in write error path pNFS: Fix NULL dereference in pnfs_generic_alloc_ds_commits Hou Tao (1): NFS: always treat the invocation of nfs_getattr as cache hit when noac is on NeilBrown (2): NFS: fix usage of mempools. sunrpc: don't check for failure from mempool_alloc() Olga Kornievskaia (2): NFS4.1 handle interrupted slot reuse from ERR_DELAY NFS append COMMIT after synchronous COPY Pan Bian (1): NFSv4: check return value of xdr_inline_decode Tigran Mkrtchyan (1): nfs: flexfilelayout: remove v3-only data server limitation Trond Myklebust (24): NFSv4: Fix a hang in OPEN related to server reboot pNFS/flexfiles: Check the result of nfs4_pnfs_ds_connect pNFS: Remove unused layout driver callbacks pNFS: Unexport pnfs_put_lseg_locked and _pnfs_return_layout pNFS: unexport nfs4_pnfs_v3_ds_connect_unload pNFS: Ensure we check layout segment validity in the pg_init() callback pNFS: Fix use after free issues in pnfs_do_read() NFS: Don't write back further requests if there is a pending write error NFSv3: nfs3_nlm_alloc_call should be declared static Merge tag 'nfs-rdma-4.12-1' of git://git.linux-nfs.org/projects/anna/nfs-rdma NFS: Add a few more fatal I/O errors to nfs_error_is_fatal() NFSv4: Don't special case "launder" pNFS: Ensure we check layout validity before marking it for return pNFS/flexfiles: Fix up the ff_layout_write_pagelist failure path pNFS: Don't send COMMITs to the DSes if the server invalidated our layout pNFS: Ensure we commit the layout if it has been invalidated pNFS: Don't clear the layout return info if there are segments to return pNFS: Fix a deadlock when coalescing writes and returning the layout pNFS: Fix a typo in pnfs_generic_alloc_ds_commits NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION NFSv4: Fix an rcu lock leak NFSv4: Fix exclusive create attributes encoding NFSv4.1: Work around a Linux server bug... pNFS/flexfiles: Always attempt to call layoutstats when flexfiles is enabled Documentation/admin-guide/kernel-parameters.txt | 6 - Documentation/filesystems/nfs/pnfs.txt | 37 -- fs/fuse/file.c | 2 +- fs/lockd/clntlock.c | 1 + fs/lockd/clntproc.c | 26 +- fs/locks.c | 2 +- fs/nfs/Kconfig | 5 - fs/nfs/Makefile | 1 - fs/nfs/callback_proc.c | 47 +- fs/nfs/callback_xdr.c | 109 +--- fs/nfs/client.c | 67 +-- fs/nfs/dir.c | 104 +--- fs/nfs/direct.c | 21 +- fs/nfs/file.c | 30 +- fs/nfs/filelayout/filelayout.c | 8 +- fs/nfs/flexfilelayout/flexfilelayout.c | 24 +- fs/nfs/flexfilelayout/flexfilelayoutdev.c | 10 +- fs/nfs/inode.c | 5 +- fs/nfs/internal.h | 5 +- fs/nfs/namespace.c | 34 +- fs/nfs/nfs3proc.c | 54 +- fs/nfs/nfs42proc.c | 24 +- fs/nfs/nfs42xdr.c | 22 +- fs/nfs/nfs4client.c | 283 +++------- fs/nfs/nfs4getroot.c | 3 - fs/nfs/nfs4namespace.c | 7 +- fs/nfs/nfs4proc.c | 99 ++-- fs/nfs/nfs4state.c | 10 +- fs/nfs/nfs4xdr.c | 94 ++-- fs/nfs/objlayout/Kbuild | 5 - fs/nfs/objlayout/objio_osd.c | 675 ---------------------- fs/nfs/objlayout/objlayout.c | 706 ------------------------ fs/nfs/objlayout/objlayout.h | 183 ------ fs/nfs/objlayout/pnfs_osd_xdr_cli.c | 415 -------------- fs/nfs/pagelist.c | 77 ++- fs/nfs/pnfs.c | 62 ++- fs/nfs/pnfs.h | 6 +- fs/nfs/pnfs_nfs.c | 24 +- fs/nfs/proc.c | 2 +- fs/nfs/read.c | 9 +- fs/nfs/write.c | 121 ++-- include/linux/fs.h | 2 + include/linux/lockd/bind.h | 24 +- include/linux/lockd/lockd.h | 2 + include/linux/nfs_fs.h | 17 +- include/linux/nfs_fs_sb.h | 1 + include/linux/nfs_page.h | 5 +- include/linux/nfs_xdr.h | 3 + net/sunrpc/clnt.c | 8 - net/sunrpc/sched.c | 5 - net/sunrpc/xdr.c | 2 +- net/sunrpc/xprt.c | 1 + net/sunrpc/xprtrdma/rpc_rdma.c | 12 +- net/sunrpc/xprtrdma/transport.c | 57 +- net/sunrpc/xprtrdma/verbs.c | 323 +++++++---- net/sunrpc/xprtrdma/xprt_rdma.h | 22 +- 56 files changed, 949 insertions(+), 2960 deletions(-) delete mode 100644 fs/nfs/objlayout/Kbuild delete mode 100644 fs/nfs/objlayout/objio_osd.c delete mode 100644 fs/nfs/objlayout/objlayout.c delete mode 100644 fs/nfs/objlayout/objlayout.h delete mode 100644 fs/nfs/objlayout/pnfs_osd_xdr_cli.c -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-10 16:47 ` Trond Myklebust (?) @ 2017-05-10 20:06 ` Linus Torvalds -1 siblings, 0 replies; 20+ messages in thread From: Linus Torvalds @ 2017-05-10 20:06 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org On Wed, May 10, 2017 at 9:47 AM, Trond Myklebust <trondmy@primarydata.com> wrote: > > Features: > - Removal of the unmaintained and unused OSD pNFS layout > - Cleanup and removal of lots of unnecessary dprintk()s > - Cleanup and removal of some memory failure paths now that > .. > 56 files changed, 949 insertions(+), 2960 deletions(-) Lovely. Thanks, Linus ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-10 16:47 ` Trond Myklebust (?) (?) @ 2017-05-11 7:53 ` Nikolay Borisov 2017-05-11 7:59 ` Michal Hocko 2017-05-11 13:41 ` Trond Myklebust -1 siblings, 2 replies; 20+ messages in thread From: Nikolay Borisov @ 2017-05-11 7:53 UTC (permalink / raw) To: Trond Myklebust, torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, Michal Hocko On 10.05.2017 19:47, Trond Myklebust wrote: > Hi Linus, > > The following changes since commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3: > > Linux 4.11-rc7 (2017-04-16 13:00:18 -0700) > > are available in the git repository at: > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.12-1 > > for you to fetch changes up to 76b2a303384e1d6299c3a0249f0f0ce2f8f96017: > > pNFS/flexfiles: Always attempt to call layoutstats when flexfiles is enabled (2017-05-09 16:02:57 -0400) > > ---------------------------------------------------------------- > NFS client updates for Linux 4.12 > > Highlights include: > > Stable bugfixes: > - Fix use after free in write error path > - Use GFP_NOIO for two allocations in writeback > - Fix a hang in OPEN related to server reboot > - Check the result of nfs4_pnfs_ds_connect > - Fix an rcu lock leak > > Features: > - Removal of the unmaintained and unused OSD pNFS layout > - Cleanup and removal of lots of unnecessary dprintk()s > - Cleanup and removal of some memory failure paths now that > GFP_NOFS is guaranteed to never fail. What guarantees that? Since if this is the case then this can result in a lot of opportunities for cleanup across the whole kernel tree. After discussing with mhocko (cc'ed) it seems that in practice everything below COSTLY_ORDER which are not GFP_NORETRY will never fail. But this semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees that this will stay like that in the future? [omitted for brevity] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 7:53 ` Nikolay Borisov @ 2017-05-11 7:59 ` Michal Hocko 2017-05-11 12:16 ` Trond Myklebust 2017-05-11 13:41 ` Trond Myklebust 1 sibling, 1 reply; 20+ messages in thread From: Michal Hocko @ 2017-05-11 7:59 UTC (permalink / raw) To: Nikolay Borisov Cc: Trond Myklebust, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > On 10.05.2017 19:47, Trond Myklebust wrote: [...] > > - Cleanup and removal of some memory failure paths now that > > GFP_NOFS is guaranteed to never fail. > > What guarantees that? Since if this is the case then this can result in > a lot of opportunities for cleanup across the whole kernel tree. After > discussing with mhocko (cc'ed) it seems that in practice everything > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But this > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees that > this will stay like that in the future? In practice it is hard to change the semantic of small allocations never fail _practically_. But this is absolutely not guaranteed! They can fail e.g. when the allocation context is the oom victim. Removing error paths for allocation failures is just wrong. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 7:59 ` Michal Hocko @ 2017-05-11 12:16 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 12:16 UTC (permalink / raw) To: mhocko@kernel.org, n.borisov.lkml@gmail.com Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org T24gVGh1LCAyMDE3LTA1LTExIGF0IDA5OjU5ICswMjAwLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+ IE9uIFRodSAxMS0wNS0xNyAxMDo1MzoyNywgTmlrb2xheSBCb3Jpc292IHdyb3RlOg0KPiA+IA0K PiA+IA0KPiA+IE9uIDEwLjA1LjIwMTcgMTk6NDcsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4g DQo+IFsuLi5dDQo+ID4gPiAtIENsZWFudXAgYW5kIHJlbW92YWwgb2Ygc29tZSBtZW1vcnkgZmFp bHVyZSBwYXRocyBub3cgdGhhdA0KPiA+ID4gwqAgR0ZQX05PRlMgaXMgZ3VhcmFudGVlZCB0byBu ZXZlciBmYWlsLg0KPiA+IA0KPiA+IFdoYXQgZ3VhcmFudGVlcyB0aGF0PyBTaW5jZSBpZiB0aGlz IGlzIHRoZSBjYXNlIHRoZW4gdGhpcyBjYW4NCj4gPiByZXN1bHQgaW4NCj4gPiBhIGxvdCBvZiBv cHBvcnR1bml0aWVzIGZvciBjbGVhbnVwIGFjcm9zcyB0aGUgd2hvbGUga2VybmVsIHRyZWUuDQo+ ID4gQWZ0ZXINCj4gPiBkaXNjdXNzaW5nIHdpdGggbWhvY2tvIChjYydlZCkgaXQgc2VlbXMgdGhh dCBpbiBwcmFjdGljZSBldmVyeXRoaW5nDQo+ID4gYmVsb3cgQ09TVExZX09SREVSIHdoaWNoIGFy ZSBub3QgR0ZQX05PUkVUUlkgd2lsbCBuZXZlciBmYWlsLiBCdXQNCj4gPiB0aGlzDQo+ID4gc2Vt YW50aWMgaXMgbm90IHRoZSBzYW1lIGFzIEdGUF9OT0ZBSUwuIEUuZy4gbm90aGluZyBndWFyYW50 ZWVzDQo+ID4gdGhhdA0KPiA+IHRoaXMgd2lsbCBzdGF5IGxpa2UgdGhhdCBpbiB0aGUgZnV0dXJl Pw0KPiANCj4gSW4gcHJhY3RpY2UgaXQgaXMgaGFyZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljIG9m IHNtYWxsIGFsbG9jYXRpb25zDQo+IG5ldmVyDQo+IGZhaWwgX3ByYWN0aWNhbGx5Xy4gQnV0IHRo aXMgaXMgYWJzb2x1dGVseSBub3QgZ3VhcmFudGVlZCEgVGhleSBjYW4NCj4gZmFpbA0KPiBlLmcu IHdoZW4gdGhlIGFsbG9jYXRpb24gY29udGV4dCBpcyB0aGUgb29tIHZpY3RpbS4gUmVtb3Zpbmcg ZXJyb3INCj4gcGF0aHMNCj4gZm9yIGFsbG9jYXRpb24gZmFpbHVyZXMgaXMganVzdCB3cm9uZy4N Cg0KT0ssIHRoaXMgbWFrZXMgbm8gZnVja2luZyBzZW5zZSBhdCBhbGwuDQoNCkVpdGhlciBhbGxv Y2F0aW9ucyBjYW4gZmFpbCBvciB0aGV5IGNhbid0Lg0KMSkgSWYgdGhleSBjYW4ndCBmYWlsLCB0 aGVuIHdlIGRvbid0IG5lZWQgdGhlIGNoZWNrcy4NCjIpIElmIHRoZXkgY2FuIGZhaWwsIHRoZW4g d2UgZG8gbmVlZCB0aGVtLCBhbmQgdGhpcyBoYW5kIHdyaW5naW5nIGluDQp0aGUgTU0gY29tbXVu aXR5IGFib3V0IEdGUF8qIHNlbWFudGljcyBhbmQgaG93IHdlIG5lZWQgdG8gcHJldmVudA0KZmFp bHVyZSBpcyBmdWNraW5nIHBvaW50bGVzcy4NCg0KU28gd2hpY2ggaXMgaXQ/ICgxKSBvciAoMik/ DQoNCg0KDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWlu ZXIsIFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-11 12:16 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 12:16 UTC (permalink / raw) To: mhocko@kernel.org, n.borisov.lkml@gmail.com Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > [...] > > > - Cleanup and removal of some memory failure paths now that > > > GFP_NOFS is guaranteed to never fail. > > > > What guarantees that? Since if this is the case then this can > > result in > > a lot of opportunities for cleanup across the whole kernel tree. > > After > > discussing with mhocko (cc'ed) it seems that in practice everything > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > > this > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > that > > this will stay like that in the future? > > In practice it is hard to change the semantic of small allocations > never > fail _practically_. But this is absolutely not guaranteed! They can > fail > e.g. when the allocation context is the oom victim. Removing error > paths > for allocation failures is just wrong. OK, this makes no fucking sense at all. Either allocations can fail or they can't. 1) If they can't fail, then we don't need the checks. 2) If they can fail, then we do need them, and this hand wringing in the MM community about GFP_* semantics and how we need to prevent failure is fucking pointless. So which is it? (1) or (2)? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 12:16 ` Trond Myklebust (?) @ 2017-05-11 12:26 ` Michal Hocko 2017-05-11 12:45 ` Trond Myklebust -1 siblings, 1 reply; 20+ messages in thread From: Michal Hocko @ 2017-05-11 12:26 UTC (permalink / raw) To: Trond Myklebust Cc: n.borisov.lkml@gmail.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > [...] > > > > - Cleanup and removal of some memory failure paths now that > > > > GFP_NOFS is guaranteed to never fail. > > > > > > What guarantees that? Since if this is the case then this can > > > result in > > > a lot of opportunities for cleanup across the whole kernel tree. > > > After > > > discussing with mhocko (cc'ed) it seems that in practice everything > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > > > this > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > that > > > this will stay like that in the future? > > > > In practice it is hard to change the semantic of small allocations > > never > > fail _practically_. But this is absolutely not guaranteed! They can > > fail > > e.g. when the allocation context is the oom victim. Removing error > > paths > > for allocation failures is just wrong. > > OK, this makes no fucking sense at all. > > Either allocations can fail or they can't. > 1) If they can't fail, then we don't need the checks. > 2) If they can fail, then we do need them, and this hand wringing in > the MM community about GFP_* semantics and how we need to prevent > failure is fucking pointless. everything which is not __GFP_NOFAIL might fail. We try hard not to fail small allocations requests as much as we can in general but you _have_ to check for failures. There is simply no way to guarantee "never fail" semantic for all allocation requests. This has been like that basically since years. And even this try-to-be-nofailing for small allocations has been PITA for some corner cases. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 12:26 ` Michal Hocko @ 2017-05-11 12:45 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 12:45 UTC (permalink / raw) To: mhocko@kernel.org Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com T24gVGh1LCAyMDE3LTA1LTExIGF0IDE0OjI2ICswMjAwLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+ IE9uIFRodSAxMS0wNS0xNyAxMjoxNjozNywgVHJvbmQgTXlrbGVidXN0IHdyb3RlOg0KPiA+IE9u IFRodSwgMjAxNy0wNS0xMSBhdCAwOTo1OSArMDIwMCwgTWljaGFsIEhvY2tvIHdyb3RlOg0KPiA+ ID4gT24gVGh1IDExLTA1LTE3IDEwOjUzOjI3LCBOaWtvbGF5IEJvcmlzb3Ygd3JvdGU6DQo+ID4g PiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gT24gMTAuMDUuMjAxNyAxOTo0NywgVHJvbmQgTXlrbGVi dXN0IHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBbLi4uXQ0KPiA+ID4gPiA+IC0gQ2xlYW51cCBhbmQg cmVtb3ZhbCBvZiBzb21lIG1lbW9yeSBmYWlsdXJlIHBhdGhzIG5vdyB0aGF0DQo+ID4gPiA+ID4g wqAgR0ZQX05PRlMgaXMgZ3VhcmFudGVlZCB0byBuZXZlciBmYWlsLg0KPiA+ID4gPiANCj4gPiA+ ID4gV2hhdCBndWFyYW50ZWVzIHRoYXQ/IFNpbmNlIGlmIHRoaXMgaXMgdGhlIGNhc2UgdGhlbiB0 aGlzIGNhbg0KPiA+ID4gPiByZXN1bHQgaW4NCj4gPiA+ID4gYSBsb3Qgb2Ygb3Bwb3J0dW5pdGll cyBmb3IgY2xlYW51cCBhY3Jvc3MgdGhlIHdob2xlIGtlcm5lbA0KPiA+ID4gPiB0cmVlLg0KPiA+ ID4gPiBBZnRlcg0KPiA+ID4gPiBkaXNjdXNzaW5nIHdpdGggbWhvY2tvIChjYydlZCkgaXQgc2Vl bXMgdGhhdCBpbiBwcmFjdGljZQ0KPiA+ID4gPiBldmVyeXRoaW5nDQo+ID4gPiA+IGJlbG93IENP U1RMWV9PUkRFUiB3aGljaCBhcmUgbm90IEdGUF9OT1JFVFJZIHdpbGwgbmV2ZXIgZmFpbC4NCj4g PiA+ID4gQnV0DQo+ID4gPiA+IHRoaXMNCj4gPiA+ID4gc2VtYW50aWMgaXMgbm90IHRoZSBzYW1l IGFzIEdGUF9OT0ZBSUwuIEUuZy4gbm90aGluZyBndWFyYW50ZWVzDQo+ID4gPiA+IHRoYXQNCj4g PiA+ID4gdGhpcyB3aWxsIHN0YXkgbGlrZSB0aGF0IGluIHRoZSBmdXR1cmU/DQo+ID4gPiANCj4g PiA+IEluIHByYWN0aWNlIGl0IGlzIGhhcmQgdG8gY2hhbmdlIHRoZSBzZW1hbnRpYyBvZiBzbWFs bA0KPiA+ID4gYWxsb2NhdGlvbnMNCj4gPiA+IG5ldmVyDQo+ID4gPiBmYWlsIF9wcmFjdGljYWxs eV8uIEJ1dCB0aGlzIGlzIGFic29sdXRlbHkgbm90IGd1YXJhbnRlZWQhIFRoZXkNCj4gPiA+IGNh bg0KPiA+ID4gZmFpbA0KPiA+ID4gZS5nLiB3aGVuIHRoZSBhbGxvY2F0aW9uIGNvbnRleHQgaXMg dGhlIG9vbSB2aWN0aW0uIFJlbW92aW5nDQo+ID4gPiBlcnJvcg0KPiA+ID4gcGF0aHMNCj4gPiA+ IGZvciBhbGxvY2F0aW9uIGZhaWx1cmVzIGlzIGp1c3Qgd3JvbmcuDQo+ID4gDQo+ID4gT0ssIHRo aXMgbWFrZXMgbm8gZnVja2luZyBzZW5zZSBhdCBhbGwuDQo+ID4gDQo+ID4gRWl0aGVyIGFsbG9j YXRpb25zIGNhbiBmYWlsIG9yIHRoZXkgY2FuJ3QuDQo+ID4gMSkgSWYgdGhleSBjYW4ndCBmYWls LCB0aGVuIHdlIGRvbid0IG5lZWQgdGhlIGNoZWNrcy4NCj4gPiAyKSBJZiB0aGV5IGNhbiBmYWls LCB0aGVuIHdlIGRvIG5lZWQgdGhlbSwgYW5kIHRoaXMgaGFuZCB3cmluZ2luZw0KPiA+IGluDQo+ ID4gdGhlIE1NIGNvbW11bml0eSBhYm91dCBHRlBfKiBzZW1hbnRpY3MgYW5kIGhvdyB3ZSBuZWVk IHRvIHByZXZlbnQNCj4gPiBmYWlsdXJlIGlzIGZ1Y2tpbmcgcG9pbnRsZXNzLg0KPiANCj4gZXZl cnl0aGluZyB3aGljaCBpcyBub3QgX19HRlBfTk9GQUlMIG1pZ2h0IGZhaWwuIFdlIHRyeSBoYXJk IG5vdCB0bw0KPiBmYWlsDQo+IHNtYWxsIGFsbG9jYXRpb25zIHJlcXVlc3RzIGFzIG11Y2ggYXMg d2UgY2FuIGluIGdlbmVyYWwgYnV0IHlvdQ0KPiBfaGF2ZV8gdG8NCj4gY2hlY2sgZm9yIGZhaWx1 cmVzLiBUaGVyZSBpcyBzaW1wbHkgbm8gd2F5IHRvIGd1YXJhbnRlZSAibmV2ZXIgZmFpbCINCj4g c2VtYW50aWMgZm9yIGFsbCBhbGxvY2F0aW9uIHJlcXVlc3RzLiBUaGlzIGhhcyBiZWVuIGxpa2Ug dGhhdA0KPiBiYXNpY2FsbHkNCj4gc2luY2UgeWVhcnMuIEFuZCBldmVuIHRoaXMgdHJ5LXRvLWJl LW5vZmFpbGluZyBmb3Igc21hbGwgYWxsb2NhdGlvbnMNCj4gaGFzDQo+IGJlZW4gUElUQSBmb3Ig c29tZSBjb3JuZXIgY2FzZXMuDQoNCkknbGwgdGFrZSB0aGF0IGFzIGEgdm90ZSBmb3IgKDIpLCB0 aGVuLg0KDQpJIGtub3cgdGhhdCBmYWlsdXJlcyBjb3VsZCBvY2N1ciBpbiB0aGUgcGFzdC4gVGhh dCdzIHdoeSB0aG9zZSBjb2RlDQpwYXRocyB3ZXJlIHRoZXJlLiBUaGUgcHJvYmxlbSBpcyB0aGF0 IHRoZSBNTSBjb21tdW5pdHkgaGFzIGJlZW4gbWFraW5nDQpsb3RzIG9mIG5vaXNlIG9uIG1haWxp bmcgbGlzdHMsIGNvbmZlcmVuY2VzIGFuZCBMV04gYXJ0aWNsZXMgYWJvdXQgaG93DQp3ZSBtdXN0 IG5vdCBmYWlsIHNtYWxsIGFsbG9jYXRpb25zIGJlY2F1c2UgdGhlIE1NIGNvbW11bml0eSBiZWxp ZXZlcw0KdGhhdCBub2JvZHkgZXhwZWN0cyBpdC4gVGhpcyBpcyBjb25mdXNpbmcgZXZlcnlvbmUu Li4gSXQgY29uZnVzZWQgTmVpbA0KQnJvd24sIHdobyBjb250cmlidXRlZCB0aGVzZSBwYXRjaGVz LCBhbmQgaXQgY29uZnVzZWQgbWUgYW5kIGFsbCB0aGUNCm90aGVyIHJldmlld2VycyBvZiB0aGVz ZSBwYXRjaGVzIG9uIHRoZSBsaW51eC1uZnMgbWFpbGluZyBsaXN0Lg0KDQpTbyBpZiBpbmRlZWQg KDIpIGlzIGNvcnJlY3QsIHRoZW4gcGxlYXNlIGNhbiB3ZSBoYXZlIGEgY2xlYXIgc3RhdGVtZW50 DQpfd2hlbiBkaXNjdXNzaW5nIGltcHJvdmVtZW50cyB0byBtZW1vcnkgYWxsb2NhdGlvbiBzZW1h bnRpY3NfIHRoYXQNCkdGUF8qIHN0aWxsIGNhbiBmYWlsLCBzdGlsbCB3aWxsIGZhaWwsIGFuZCB0 aGF0IGNhbGxlcnMgc2hvdWxkIGFzc3VtZQ0KaXQgd2lsbCBmYWlsIGFuZCBzaG91bGQgdGVzdCB0 aGVpciBjb2RlIHBhdGhzIGFzc3VtaW5nIHRoZSBmYWlsdXJlDQpjYXNlLg0KDQotLSANClRyb25k IE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJv bmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-11 12:45 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 12:45 UTC (permalink / raw) To: mhocko@kernel.org Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com On Thu, 2017-05-11 at 14:26 +0200, Michal Hocko wrote: > On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > > > [...] > > > > > - Cleanup and removal of some memory failure paths now that > > > > > GFP_NOFS is guaranteed to never fail. > > > > > > > > What guarantees that? Since if this is the case then this can > > > > result in > > > > a lot of opportunities for cleanup across the whole kernel > > > > tree. > > > > After > > > > discussing with mhocko (cc'ed) it seems that in practice > > > > everything > > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. > > > > But > > > > this > > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > > that > > > > this will stay like that in the future? > > > > > > In practice it is hard to change the semantic of small > > > allocations > > > never > > > fail _practically_. But this is absolutely not guaranteed! They > > > can > > > fail > > > e.g. when the allocation context is the oom victim. Removing > > > error > > > paths > > > for allocation failures is just wrong. > > > > OK, this makes no fucking sense at all. > > > > Either allocations can fail or they can't. > > 1) If they can't fail, then we don't need the checks. > > 2) If they can fail, then we do need them, and this hand wringing > > in > > the MM community about GFP_* semantics and how we need to prevent > > failure is fucking pointless. > > everything which is not __GFP_NOFAIL might fail. We try hard not to > fail > small allocations requests as much as we can in general but you > _have_ to > check for failures. There is simply no way to guarantee "never fail" > semantic for all allocation requests. This has been like that > basically > since years. And even this try-to-be-nofailing for small allocations > has > been PITA for some corner cases. I'll take that as a vote for (2), then. I know that failures could occur in the past. That's why those code paths were there. The problem is that the MM community has been making lots of noise on mailing lists, conferences and LWN articles about how we must not fail small allocations because the MM community believes that nobody expects it. This is confusing everyone... It confused Neil Brown, who contributed these patches, and it confused me and all the other reviewers of these patches on the linux-nfs mailing list. So if indeed (2) is correct, then please can we have a clear statement _when discussing improvements to memory allocation semantics_ that GFP_* still can fail, still will fail, and that callers should assume it will fail and should test their code paths assuming the failure case. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 12:45 ` Trond Myklebust (?) @ 2017-05-11 12:56 ` Michal Hocko 2017-05-11 13:10 ` Trond Myklebust -1 siblings, 1 reply; 20+ messages in thread From: Michal Hocko @ 2017-05-11 12:56 UTC (permalink / raw) To: Trond Myklebust Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com On Thu 11-05-17 12:45:00, Trond Myklebust wrote: > On Thu, 2017-05-11 at 14:26 +0200, Michal Hocko wrote: > > On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > > > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > > > > > [...] > > > > > > - Cleanup and removal of some memory failure paths now that > > > > > > GFP_NOFS is guaranteed to never fail. > > > > > > > > > > What guarantees that? Since if this is the case then this can > > > > > result in > > > > > a lot of opportunities for cleanup across the whole kernel > > > > > tree. > > > > > After > > > > > discussing with mhocko (cc'ed) it seems that in practice > > > > > everything > > > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. > > > > > But > > > > > this > > > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > > > that > > > > > this will stay like that in the future? > > > > > > > > In practice it is hard to change the semantic of small > > > > allocations > > > > never > > > > fail _practically_. But this is absolutely not guaranteed! They > > > > can > > > > fail > > > > e.g. when the allocation context is the oom victim. Removing > > > > error > > > > paths > > > > for allocation failures is just wrong. > > > > > > OK, this makes no fucking sense at all. > > > > > > Either allocations can fail or they can't. > > > 1) If they can't fail, then we don't need the checks. > > > 2) If they can fail, then we do need them, and this hand wringing > > > in > > > the MM community about GFP_* semantics and how we need to prevent > > > failure is fucking pointless. > > > > everything which is not __GFP_NOFAIL might fail. We try hard not to > > fail > > small allocations requests as much as we can in general but you > > _have_ to > > check for failures. There is simply no way to guarantee "never fail" > > semantic for all allocation requests. This has been like that > > basically > > since years. And even this try-to-be-nofailing for small allocations > > has > > been PITA for some corner cases. > > I'll take that as a vote for (2), then. > > I know that failures could occur in the past. That's why those code > paths were there. The problem is that the MM community has been making > lots of noise on mailing lists, conferences and LWN articles about how > we must not fail small allocations because the MM community believes > that nobody expects it. This is confusing everyone... It was exactly other way around. We would like to _get_rid_of_ this do not fail behavior because it is causing a major headaches in out of memory corner cases. Just take GFP_NOFS as an example. It is a weak reclaim context because we cannot reclaim fs metadata and that might be a lot of memory so we cannot trigger the OOM killer and have to rely on a different allocation context or kswapd to make a progress on our behalf. We would really like to fail those requests instead. I've tried that in the past but it was deemed to dangerous because _all_ kernel paths would have to be checked for a sane failure behavior. So we are keeping status quo instead. > It confused Neil Brown, who contributed these patches, and it confused > me and all the other reviewers of these patches on the linux-nfs > mailing list. > > So if indeed (2) is correct, then please can we have a clear statement > _when discussing improvements to memory allocation semantics_ that > GFP_* still can fail, still will fail, and that callers should assume > it will fail and should test their code paths assuming the failure > case. I do not see any explicit documentation which would encourage users to not check for the allocation failure. Only __GFP_NOFAIL is documented it _must_ retry for ever. Of course I am open for any documentation improvements. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 12:56 ` Michal Hocko @ 2017-05-11 13:10 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 13:10 UTC (permalink / raw) To: mhocko@kernel.org Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com T24gVGh1LCAyMDE3LTA1LTExIGF0IDE0OjU2ICswMjAwLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+ IE9uIFRodSAxMS0wNS0xNyAxMjo0NTowMCwgVHJvbmQgTXlrbGVidXN0IHdyb3RlOg0KPiA+IE9u IFRodSwgMjAxNy0wNS0xMSBhdCAxNDoyNiArMDIwMCwgTWljaGFsIEhvY2tvIHdyb3RlOg0KPiA+ ID4gT24gVGh1IDExLTA1LTE3IDEyOjE2OjM3LCBUcm9uZCBNeWtsZWJ1c3Qgd3JvdGU6DQo+ID4g PiA+IE9uIFRodSwgMjAxNy0wNS0xMSBhdCAwOTo1OSArMDIwMCwgTWljaGFsIEhvY2tvIHdyb3Rl Og0KPiA+ID4gPiA+IE9uIFRodSAxMS0wNS0xNyAxMDo1MzoyNywgTmlrb2xheSBCb3Jpc292IHdy b3RlOg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IE9uIDEwLjA1LjIw MTcgMTk6NDcsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBb Li4uXQ0KPiA+ID4gPiA+ID4gPiAtIENsZWFudXAgYW5kIHJlbW92YWwgb2Ygc29tZSBtZW1vcnkg ZmFpbHVyZSBwYXRocyBub3cNCj4gPiA+ID4gPiA+ID4gdGhhdA0KPiA+ID4gPiA+ID4gPiDCoCBH RlBfTk9GUyBpcyBndWFyYW50ZWVkIHRvIG5ldmVyIGZhaWwuDQo+ID4gPiA+ID4gPiANCj4gPiA+ ID4gPiA+IFdoYXQgZ3VhcmFudGVlcyB0aGF0PyBTaW5jZSBpZiB0aGlzIGlzIHRoZSBjYXNlIHRo ZW4gdGhpcw0KPiA+ID4gPiA+ID4gY2FuDQo+ID4gPiA+ID4gPiByZXN1bHQgaW4NCj4gPiA+ID4g PiA+IGEgbG90IG9mIG9wcG9ydHVuaXRpZXMgZm9yIGNsZWFudXAgYWNyb3NzIHRoZSB3aG9sZSBr ZXJuZWwNCj4gPiA+ID4gPiA+IHRyZWUuDQo+ID4gPiA+ID4gPiBBZnRlcg0KPiA+ID4gPiA+ID4g ZGlzY3Vzc2luZyB3aXRoIG1ob2NrbyAoY2MnZWQpIGl0IHNlZW1zIHRoYXQgaW4gcHJhY3RpY2UN Cj4gPiA+ID4gPiA+IGV2ZXJ5dGhpbmcNCj4gPiA+ID4gPiA+IGJlbG93IENPU1RMWV9PUkRFUiB3 aGljaCBhcmUgbm90IEdGUF9OT1JFVFJZIHdpbGwgbmV2ZXINCj4gPiA+ID4gPiA+IGZhaWwuDQo+ ID4gPiA+ID4gPiBCdXQNCj4gPiA+ID4gPiA+IHRoaXMNCj4gPiA+ID4gPiA+IHNlbWFudGljIGlz IG5vdCB0aGUgc2FtZSBhcyBHRlBfTk9GQUlMLiBFLmcuIG5vdGhpbmcNCj4gPiA+ID4gPiA+IGd1 YXJhbnRlZXMNCj4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+IHRoaXMgd2lsbCBzdGF5IGxp a2UgdGhhdCBpbiB0aGUgZnV0dXJlPw0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEluIHByYWN0aWNl IGl0IGlzIGhhcmQgdG8gY2hhbmdlIHRoZSBzZW1hbnRpYyBvZiBzbWFsbA0KPiA+ID4gPiA+IGFs bG9jYXRpb25zDQo+ID4gPiA+ID4gbmV2ZXINCj4gPiA+ID4gPiBmYWlsIF9wcmFjdGljYWxseV8u IEJ1dCB0aGlzIGlzIGFic29sdXRlbHkgbm90IGd1YXJhbnRlZWQhDQo+ID4gPiA+ID4gVGhleQ0K PiA+ID4gPiA+IGNhbg0KPiA+ID4gPiA+IGZhaWwNCj4gPiA+ID4gPiBlLmcuIHdoZW4gdGhlIGFs bG9jYXRpb24gY29udGV4dCBpcyB0aGUgb29tIHZpY3RpbS4gUmVtb3ZpbmcNCj4gPiA+ID4gPiBl cnJvcg0KPiA+ID4gPiA+IHBhdGhzDQo+ID4gPiA+ID4gZm9yIGFsbG9jYXRpb24gZmFpbHVyZXMg aXMganVzdCB3cm9uZy4NCj4gPiA+ID4gDQo+ID4gPiA+IE9LLCB0aGlzIG1ha2VzIG5vIGZ1Y2tp bmcgc2Vuc2UgYXQgYWxsLg0KPiA+ID4gPiANCj4gPiA+ID4gRWl0aGVyIGFsbG9jYXRpb25zIGNh biBmYWlsIG9yIHRoZXkgY2FuJ3QuDQo+ID4gPiA+IDEpIElmIHRoZXkgY2FuJ3QgZmFpbCwgdGhl biB3ZSBkb24ndCBuZWVkIHRoZSBjaGVja3MuDQo+ID4gPiA+IDIpIElmIHRoZXkgY2FuIGZhaWws IHRoZW4gd2UgZG8gbmVlZCB0aGVtLCBhbmQgdGhpcyBoYW5kDQo+ID4gPiA+IHdyaW5naW5nDQo+ ID4gPiA+IGluDQo+ID4gPiA+IHRoZSBNTSBjb21tdW5pdHkgYWJvdXQgR0ZQXyogc2VtYW50aWNz IGFuZCBob3cgd2UgbmVlZCB0bw0KPiA+ID4gPiBwcmV2ZW50DQo+ID4gPiA+IGZhaWx1cmUgaXMg ZnVja2luZyBwb2ludGxlc3MuDQo+ID4gPiANCj4gPiA+IGV2ZXJ5dGhpbmcgd2hpY2ggaXMgbm90 IF9fR0ZQX05PRkFJTCBtaWdodCBmYWlsLiBXZSB0cnkgaGFyZCBub3QNCj4gPiA+IHRvDQo+ID4g PiBmYWlsDQo+ID4gPiBzbWFsbCBhbGxvY2F0aW9ucyByZXF1ZXN0cyBhcyBtdWNoIGFzIHdlIGNh biBpbiBnZW5lcmFsIGJ1dCB5b3UNCj4gPiA+IF9oYXZlXyB0bw0KPiA+ID4gY2hlY2sgZm9yIGZh aWx1cmVzLiBUaGVyZSBpcyBzaW1wbHkgbm8gd2F5IHRvIGd1YXJhbnRlZSAibmV2ZXINCj4gPiA+ IGZhaWwiDQo+ID4gPiBzZW1hbnRpYyBmb3IgYWxsIGFsbG9jYXRpb24gcmVxdWVzdHMuIFRoaXMg aGFzIGJlZW4gbGlrZSB0aGF0DQo+ID4gPiBiYXNpY2FsbHkNCj4gPiA+IHNpbmNlIHllYXJzLiBB bmQgZXZlbiB0aGlzIHRyeS10by1iZS1ub2ZhaWxpbmcgZm9yIHNtYWxsDQo+ID4gPiBhbGxvY2F0 aW9ucw0KPiA+ID4gaGFzDQo+ID4gPiBiZWVuIFBJVEEgZm9yIHNvbWUgY29ybmVyIGNhc2VzLg0K PiA+IA0KPiA+IEknbGwgdGFrZSB0aGF0IGFzIGEgdm90ZSBmb3IgKDIpLCB0aGVuLg0KPiA+IA0K PiA+IEkga25vdyB0aGF0IGZhaWx1cmVzIGNvdWxkIG9jY3VyIGluIHRoZSBwYXN0LiBUaGF0J3Mg d2h5IHRob3NlIGNvZGUNCj4gPiBwYXRocyB3ZXJlIHRoZXJlLiBUaGUgcHJvYmxlbSBpcyB0aGF0 IHRoZSBNTSBjb21tdW5pdHkgaGFzIGJlZW4NCj4gPiBtYWtpbmcNCj4gPiBsb3RzIG9mIG5vaXNl IG9uIG1haWxpbmcgbGlzdHMsIGNvbmZlcmVuY2VzIGFuZCBMV04gYXJ0aWNsZXMgYWJvdXQNCj4g PiBob3cNCj4gPiB3ZSBtdXN0IG5vdCBmYWlsIHNtYWxsIGFsbG9jYXRpb25zIGJlY2F1c2UgdGhl IE1NIGNvbW11bml0eQ0KPiA+IGJlbGlldmVzDQo+ID4gdGhhdCBub2JvZHkgZXhwZWN0cyBpdC4g VGhpcyBpcyBjb25mdXNpbmcgZXZlcnlvbmUuLi4NCj4gDQo+IEl0IHdhcyBleGFjdGx5IG90aGVy IHdheSBhcm91bmQuIFdlIHdvdWxkIGxpa2UgdG8gX2dldF9yaWRfb2ZfIHRoaXMNCj4gZG8NCj4g bm90IGZhaWwgYmVoYXZpb3IgYmVjYXVzZSBpdCBpcyBjYXVzaW5nIGEgbWFqb3IgaGVhZGFjaGVz IGluIG91dCBvZg0KPiBtZW1vcnkgY29ybmVyIGNhc2VzLiBKdXN0IHRha2UgR0ZQX05PRlMgYXMg YW4gZXhhbXBsZS4gSXQgaXMgYSB3ZWFrDQo+IHJlY2xhaW0gY29udGV4dCBiZWNhdXNlIHdlIGNh bm5vdCByZWNsYWltIGZzIG1ldGFkYXRhIGFuZCB0aGF0IG1pZ2h0DQo+IGJlDQo+IGEgbG90IG9m IG1lbW9yeSBzbyB3ZSBjYW5ub3QgdHJpZ2dlciB0aGUgT09NIGtpbGxlciBhbmQgaGF2ZSB0byBy ZWx5DQo+IG9uDQo+IGEgZGlmZmVyZW50IGFsbG9jYXRpb24gY29udGV4dCBvciBrc3dhcGQgdG8g bWFrZSBhIHByb2dyZXNzIG9uIG91cg0KPiBiZWhhbGYuIFdlIHdvdWxkIHJlYWxseSBsaWtlIHRv IGZhaWwgdGhvc2UgcmVxdWVzdHMgaW5zdGVhZC4gSSd2ZQ0KPiB0cmllZA0KPiB0aGF0IGluIHRo ZSBwYXN0IGJ1dCBpdCB3YXMgZGVlbWVkIHRvIGRhbmdlcm91cyBiZWNhdXNlIF9hbGxfIGtlcm5l bA0KPiBwYXRocyB3b3VsZCBoYXZlIHRvIGJlIGNoZWNrZWQgZm9yIGEgc2FuZSBmYWlsdXJlIGJl aGF2aW9yLiBTbyB3ZSBhcmUNCj4ga2VlcGluZyBzdGF0dXMgcXVvIGluc3RlYWQuDQoNCklmIHdl IHN1c3BlY3QgdGhlIGV4aXN0ZW5jZSBvZiBhIGxvYWQgb2YgcG90ZW50aWFsIHRpbWUgYm9tYnMg aW4gdGhlDQprZXJuZWwgZHVlIHRvIG1pc3NpbmcgY2hlY2tzLCB0aGVuIHRoZSBzdGF0dXMgcXVv IGlzIG5vdCBnb29kIGVub3VnaC4NCldlIHNob3VsZCBiZSB3b3JraW5nIG9uIHRvb2xzIHRvIGlk ZW50aWZ5IHRoZXNlIGNvZGUgcGF0aHMuDQoNClF1aXRlIGZyYW5rbHksIEknZCBsb3ZlIHRvIHNl ZSBhIGZ1enplci1saWtlIHRvb2wgdGhhdCBjYW4gcmFuZG9tbHkNCmZhaWwgYWxsb2NhdGlvbnMu IEkgY2FuIGVhc2lseSBtYWtlIG9uZSBmb3IgdGhlIE5GUyBjb2RlLCBidXQgaWYgdGhlcmUNCmlz IGEgZ2VuZXJhbCBwcm9ibGVtIGlkZW50aWZ5aW5nIGJ1Z2d5IGNvZGUsIHRoZW4gcGVyaGFwcyBp dCBzaG91bGQgYmUNCnNvbHZlZCBhdCB0aGUgTU0gbGF5ZXIgaXRzZWxmLg0KDQo+ID4gSXQgY29u ZnVzZWQgTmVpbCBCcm93biwgd2hvIGNvbnRyaWJ1dGVkIHRoZXNlIHBhdGNoZXMsIGFuZCBpdA0K PiA+IGNvbmZ1c2VkDQo+ID4gbWUgYW5kIGFsbCB0aGUgb3RoZXIgcmV2aWV3ZXJzIG9mIHRoZXNl IHBhdGNoZXMgb24gdGhlIGxpbnV4LW5mcw0KPiA+IG1haWxpbmcgbGlzdC4NCj4gPiANCj4gPiBT byBpZiBpbmRlZWQgKDIpIGlzIGNvcnJlY3QsIHRoZW4gcGxlYXNlIGNhbiB3ZSBoYXZlIGEgY2xl YXINCj4gPiBzdGF0ZW1lbnQNCj4gPiBfd2hlbiBkaXNjdXNzaW5nIGltcHJvdmVtZW50cyB0byBt ZW1vcnkgYWxsb2NhdGlvbiBzZW1hbnRpY3NfIHRoYXQNCj4gPiBHRlBfKiBzdGlsbCBjYW4gZmFp bCwgc3RpbGwgd2lsbCBmYWlsLCBhbmQgdGhhdCBjYWxsZXJzIHNob3VsZA0KPiA+IGFzc3VtZQ0K PiA+IGl0IHdpbGwgZmFpbCBhbmQgc2hvdWxkIHRlc3QgdGhlaXIgY29kZSBwYXRocyBhc3N1bWlu ZyB0aGUgZmFpbHVyZQ0KPiA+IGNhc2UuDQo+IA0KPiBJIGRvIG5vdCBzZWUgYW55IGV4cGxpY2l0 IGRvY3VtZW50YXRpb24gd2hpY2ggd291bGQgZW5jb3VyYWdlIHVzZXJzDQo+IHRvDQo+IG5vdCBj aGVjayBmb3IgdGhlIGFsbG9jYXRpb24gZmFpbHVyZS4gT25seSBfX0dGUF9OT0ZBSUwgaXMgZG9j dW1lbnRlZA0KPiBpdA0KPiBfbXVzdF8gcmV0cnkgZm9yIGV2ZXIuIE9mIGNvdXJzZSBJIGFtIG9w ZW4gZm9yIGFueSBkb2N1bWVudGF0aW9uDQo+IGltcHJvdmVtZW50cy4NCg0KQXMgSSBzYWlkLCB0 aGUgcHJvYmxlbSBoYXMgYmVlbiB0aGUgZGlzY3Vzc2lvbiwgYW5kIGhvdyBpdCBmb2N1c3NlcyBv bg0KIm11c3Qgbm90IGZhaWwiLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNs aWVudCBtYWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRh LmNvbQ0K ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-11 13:10 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 13:10 UTC (permalink / raw) To: mhocko@kernel.org Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com On Thu, 2017-05-11 at 14:56 +0200, Michal Hocko wrote: > On Thu 11-05-17 12:45:00, Trond Myklebust wrote: > > On Thu, 2017-05-11 at 14:26 +0200, Michal Hocko wrote: > > > On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > > > > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > > > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > > > > > > > [...] > > > > > > > - Cleanup and removal of some memory failure paths now > > > > > > > that > > > > > > > GFP_NOFS is guaranteed to never fail. > > > > > > > > > > > > What guarantees that? Since if this is the case then this > > > > > > can > > > > > > result in > > > > > > a lot of opportunities for cleanup across the whole kernel > > > > > > tree. > > > > > > After > > > > > > discussing with mhocko (cc'ed) it seems that in practice > > > > > > everything > > > > > > below COSTLY_ORDER which are not GFP_NORETRY will never > > > > > > fail. > > > > > > But > > > > > > this > > > > > > semantic is not the same as GFP_NOFAIL. E.g. nothing > > > > > > guarantees > > > > > > that > > > > > > this will stay like that in the future? > > > > > > > > > > In practice it is hard to change the semantic of small > > > > > allocations > > > > > never > > > > > fail _practically_. But this is absolutely not guaranteed! > > > > > They > > > > > can > > > > > fail > > > > > e.g. when the allocation context is the oom victim. Removing > > > > > error > > > > > paths > > > > > for allocation failures is just wrong. > > > > > > > > OK, this makes no fucking sense at all. > > > > > > > > Either allocations can fail or they can't. > > > > 1) If they can't fail, then we don't need the checks. > > > > 2) If they can fail, then we do need them, and this hand > > > > wringing > > > > in > > > > the MM community about GFP_* semantics and how we need to > > > > prevent > > > > failure is fucking pointless. > > > > > > everything which is not __GFP_NOFAIL might fail. We try hard not > > > to > > > fail > > > small allocations requests as much as we can in general but you > > > _have_ to > > > check for failures. There is simply no way to guarantee "never > > > fail" > > > semantic for all allocation requests. This has been like that > > > basically > > > since years. And even this try-to-be-nofailing for small > > > allocations > > > has > > > been PITA for some corner cases. > > > > I'll take that as a vote for (2), then. > > > > I know that failures could occur in the past. That's why those code > > paths were there. The problem is that the MM community has been > > making > > lots of noise on mailing lists, conferences and LWN articles about > > how > > we must not fail small allocations because the MM community > > believes > > that nobody expects it. This is confusing everyone... > > It was exactly other way around. We would like to _get_rid_of_ this > do > not fail behavior because it is causing a major headaches in out of > memory corner cases. Just take GFP_NOFS as an example. It is a weak > reclaim context because we cannot reclaim fs metadata and that might > be > a lot of memory so we cannot trigger the OOM killer and have to rely > on > a different allocation context or kswapd to make a progress on our > behalf. We would really like to fail those requests instead. I've > tried > that in the past but it was deemed to dangerous because _all_ kernel > paths would have to be checked for a sane failure behavior. So we are > keeping status quo instead. If we suspect the existence of a load of potential time bombs in the kernel due to missing checks, then the status quo is not good enough. We should be working on tools to identify these code paths. Quite frankly, I'd love to see a fuzzer-like tool that can randomly fail allocations. I can easily make one for the NFS code, but if there is a general problem identifying buggy code, then perhaps it should be solved at the MM layer itself. > > It confused Neil Brown, who contributed these patches, and it > > confused > > me and all the other reviewers of these patches on the linux-nfs > > mailing list. > > > > So if indeed (2) is correct, then please can we have a clear > > statement > > _when discussing improvements to memory allocation semantics_ that > > GFP_* still can fail, still will fail, and that callers should > > assume > > it will fail and should test their code paths assuming the failure > > case. > > I do not see any explicit documentation which would encourage users > to > not check for the allocation failure. Only __GFP_NOFAIL is documented > it > _must_ retry for ever. Of course I am open for any documentation > improvements. As I said, the problem has been the discussion, and how it focusses on "must not fail". -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 13:10 ` Trond Myklebust (?) @ 2017-05-11 13:27 ` Michal Hocko -1 siblings, 0 replies; 20+ messages in thread From: Michal Hocko @ 2017-05-11 13:27 UTC (permalink / raw) To: Trond Myklebust Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com On Thu 11-05-17 13:10:03, Trond Myklebust wrote: > On Thu, 2017-05-11 at 14:56 +0200, Michal Hocko wrote: [...] > > I do not see any explicit documentation which would encourage users > > to not check for the allocation failure. Only __GFP_NOFAIL is > > documented it _must_ retry for ever. Of course I am open for any > > documentation improvements. > > As I said, the problem has been the discussion, and how it focusses on > "must not fail". I would strongly suggest cc linux-mm ML when doing this kind of changes. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 13:10 ` Trond Myklebust (?) (?) @ 2017-05-16 15:15 ` Jonathan Corbet -1 siblings, 0 replies; 20+ messages in thread From: Jonathan Corbet @ 2017-05-16 15:15 UTC (permalink / raw) To: Trond Myklebust Cc: mhocko@kernel.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, n.borisov.lkml@gmail.com On Thu, 11 May 2017 13:10:03 +0000 Trond Myklebust <trondmy@primarydata.com> wrote: > If we suspect the existence of a load of potential time bombs in the > kernel due to missing checks, then the status quo is not good enough. > We should be working on tools to identify these code paths. > > Quite frankly, I'd love to see a fuzzer-like tool that can randomly > fail allocations. The fault injection framework at least used to work quite nicely for this; I used it to test out the failure paths in the OLPC drivers years ago. Documentation/fault-injection/fault-injection.txt. jon ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 7:53 ` Nikolay Borisov @ 2017-05-11 13:41 ` Trond Myklebust 2017-05-11 13:41 ` Trond Myklebust 1 sibling, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 13:41 UTC (permalink / raw) To: torvalds@linux-foundation.org, n.borisov.lkml@gmail.com Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, mhocko@suse.com T24gVGh1LCAyMDE3LTA1LTExIGF0IDEwOjUzICswMzAwLCBOaWtvbGF5IEJvcmlzb3Ygd3JvdGU6 DQo+IA0KPiBPbiAxMC4wNS4yMDE3IDE5OjQ3LCBUcm9uZCBNeWtsZWJ1c3Qgd3JvdGU6DQo+ID4g SGkgTGludXMsDQo+ID4gDQo+ID4gVGhlIGZvbGxvd2luZyBjaGFuZ2VzIHNpbmNlIGNvbW1pdA0K PiA+IDRmN2QwMjliOWJmMDA5ZmJlZTc2YmIxMGMwYzQzNTFhMTg3MGQyZjM6DQo+ID4gDQo+ID4g wqAgTGludXggNC4xMS1yYzcgKDIwMTctMDQtMTYgMTM6MDA6MTggLTA3MDApDQo+ID4gDQo+ID4g YXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgYXQ6DQo+ID4gDQo+ID4gwqAgZ2l0 Oi8vZ2l0LmxpbnV4LW5mcy5vcmcvcHJvamVjdHMvdHJvbmRteS9saW51eC1uZnMuZ2l0IHRhZ3Mv bmZzLQ0KPiA+IGZvci00LjEyLTENCj4gPiANCj4gPiBmb3IgeW91IHRvIGZldGNoIGNoYW5nZXMg dXAgdG8NCj4gPiA3NmIyYTMwMzM4NGUxZDYyOTljM2EwMjQ5ZjBmMGNlMmY4Zjk2MDE3Og0KPiA+ IA0KPiA+IMKgIHBORlMvZmxleGZpbGVzOiBBbHdheXMgYXR0ZW1wdCB0byBjYWxsIGxheW91dHN0 YXRzIHdoZW4gZmxleGZpbGVzDQo+ID4gaXMgZW5hYmxlZCAoMjAxNy0wNS0wOSAxNjowMjo1NyAt MDQwMCkNCj4gPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gTkZTIGNsaWVudCB1cGRhdGVzIGZvciBMaW51 eCA0LjEyDQo+ID4gDQo+ID4gSGlnaGxpZ2h0cyBpbmNsdWRlOg0KPiA+IA0KPiA+IFN0YWJsZSBi dWdmaXhlczoNCj4gPiAtIEZpeCB1c2UgYWZ0ZXIgZnJlZSBpbiB3cml0ZSBlcnJvciBwYXRoDQo+ ID4gLSBVc2UgR0ZQX05PSU8gZm9yIHR3byBhbGxvY2F0aW9ucyBpbiB3cml0ZWJhY2sNCj4gPiAt IEZpeCBhIGhhbmcgaW4gT1BFTiByZWxhdGVkIHRvIHNlcnZlciByZWJvb3QNCj4gPiAtIENoZWNr IHRoZSByZXN1bHQgb2YgbmZzNF9wbmZzX2RzX2Nvbm5lY3QNCj4gPiAtIEZpeCBhbiByY3UgbG9j ayBsZWFrDQo+ID4gDQo+ID4gRmVhdHVyZXM6DQo+ID4gLSBSZW1vdmFsIG9mIHRoZSB1bm1haW50 YWluZWQgYW5kIHVudXNlZCBPU0QgcE5GUyBsYXlvdXQNCj4gPiAtIENsZWFudXAgYW5kIHJlbW92 YWwgb2YgbG90cyBvZiB1bm5lY2Vzc2FyeSBkcHJpbnRrKClzDQo+ID4gLSBDbGVhbnVwIGFuZCBy ZW1vdmFsIG9mIHNvbWUgbWVtb3J5IGZhaWx1cmUgcGF0aHMgbm93IHRoYXQNCj4gPiDCoCBHRlBf Tk9GUyBpcyBndWFyYW50ZWVkIHRvIG5ldmVyIGZhaWwuDQo+IA0KPiBXaGF0IGd1YXJhbnRlZXMg dGhhdD8gU2luY2UgaWYgdGhpcyBpcyB0aGUgY2FzZSB0aGVuIHRoaXMgY2FuIHJlc3VsdA0KPiBp bg0KPiBhIGxvdCBvZiBvcHBvcnR1bml0aWVzIGZvciBjbGVhbnVwIGFjcm9zcyB0aGUgd2hvbGUg a2VybmVsIHRyZWUuDQo+IEFmdGVyDQo+IGRpc2N1c3Npbmcgd2l0aCBtaG9ja28gKGNjJ2VkKSBp dCBzZWVtcyB0aGF0IGluIHByYWN0aWNlIGV2ZXJ5dGhpbmcNCj4gYmVsb3cgQ09TVExZX09SREVS IHdoaWNoIGFyZSBub3QgR0ZQX05PUkVUUlkgd2lsbCBuZXZlciBmYWlsLiBCdXQNCj4gdGhpcw0K PiBzZW1hbnRpYyBpcyBub3QgdGhlIHNhbWUgYXMgR0ZQX05PRkFJTC4gRS5nLiBub3RoaW5nIGd1 YXJhbnRlZXMgdGhhdA0KPiB0aGlzIHdpbGwgc3RheSBsaWtlIHRoYXQgaW4gdGhlIGZ1dHVyZT8N Cj4gDQoNCkFjdHVhbGx5LCBnb2luZyBiYWNrIHRvIHRoZSBjb2RlIHdpdGggY29mZmVlOiBpdCdz IHRoZSBmYWN0IHdlIGhhdmUNCm1lbXBvb2xzLCB3aXRoIGRpcmVjdCByZWNsYWltIHRoYXQgZ3Vh cmFudGVlIHRoaXMuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1h aW50YWluZXIsIFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-05-11 13:41 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-05-11 13:41 UTC (permalink / raw) To: torvalds@linux-foundation.org, n.borisov.lkml@gmail.com Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, mhocko@suse.com On Thu, 2017-05-11 at 10:53 +0300, Nikolay Borisov wrote: > > On 10.05.2017 19:47, Trond Myklebust wrote: > > Hi Linus, > > > > The following changes since commit > > 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3: > > > > Linux 4.11-rc7 (2017-04-16 13:00:18 -0700) > > > > are available in the git repository at: > > > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs- > > for-4.12-1 > > > > for you to fetch changes up to > > 76b2a303384e1d6299c3a0249f0f0ce2f8f96017: > > > > pNFS/flexfiles: Always attempt to call layoutstats when flexfiles > > is enabled (2017-05-09 16:02:57 -0400) > > > > ---------------------------------------------------------------- > > NFS client updates for Linux 4.12 > > > > Highlights include: > > > > Stable bugfixes: > > - Fix use after free in write error path > > - Use GFP_NOIO for two allocations in writeback > > - Fix a hang in OPEN related to server reboot > > - Check the result of nfs4_pnfs_ds_connect > > - Fix an rcu lock leak > > > > Features: > > - Removal of the unmaintained and unused OSD pNFS layout > > - Cleanup and removal of lots of unnecessary dprintk()s > > - Cleanup and removal of some memory failure paths now that > > GFP_NOFS is guaranteed to never fail. > > What guarantees that? Since if this is the case then this can result > in > a lot of opportunities for cleanup across the whole kernel tree. > After > discussing with mhocko (cc'ed) it seems that in practice everything > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > this > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees that > this will stay like that in the future? > Actually, going back to the code with coffee: it's the fact we have mempools, with direct reclaim that guarantee this. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] Please pull NFS client fixes for 4.12 2017-05-11 13:41 ` Trond Myklebust (?) @ 2017-05-11 13:54 ` Michal Hocko -1 siblings, 0 replies; 20+ messages in thread From: Michal Hocko @ 2017-05-11 13:54 UTC (permalink / raw) To: Trond Myklebust Cc: torvalds@linux-foundation.org, n.borisov.lkml@gmail.com, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org On Thu 11-05-17 13:41:12, Trond Myklebust wrote: > On Thu, 2017-05-11 at 10:53 +0300, Nikolay Borisov wrote: > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > Hi Linus, > > > > > > The following changes since commit > > > 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3: > > > > > > Linux 4.11-rc7 (2017-04-16 13:00:18 -0700) > > > > > > are available in the git repository at: > > > > > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs- > > > for-4.12-1 > > > > > > for you to fetch changes up to > > > 76b2a303384e1d6299c3a0249f0f0ce2f8f96017: > > > > > > pNFS/flexfiles: Always attempt to call layoutstats when flexfiles > > > is enabled (2017-05-09 16:02:57 -0400) > > > > > > ---------------------------------------------------------------- > > > NFS client updates for Linux 4.12 > > > > > > Highlights include: > > > > > > Stable bugfixes: > > > - Fix use after free in write error path > > > - Use GFP_NOIO for two allocations in writeback > > > - Fix a hang in OPEN related to server reboot > > > - Check the result of nfs4_pnfs_ds_connect > > > - Fix an rcu lock leak > > > > > > Features: > > > - Removal of the unmaintained and unused OSD pNFS layout > > > - Cleanup and removal of lots of unnecessary dprintk()s > > > - Cleanup and removal of some memory failure paths now that > > > GFP_NOFS is guaranteed to never fail. > > > > What guarantees that? Since if this is the case then this can result > > in > > a lot of opportunities for cleanup across the whole kernel tree. > > After > > discussing with mhocko (cc'ed) it seems that in practice everything > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > > this > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees that > > this will stay like that in the future? > > > > Actually, going back to the code with coffee: it's the fact we have > mempools, with direct reclaim that guarantee this. Mempools are a different story, of course. They do the their own loop on top of the underlying allocator. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-06-28 14:19 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-06-28 14:19 UTC (permalink / raw) To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org SGkgTGludXMsDQoNClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBjb21taXQgM2MyOTkzYjhj NjE0M2Q4YTU3OTM3NDZhNTRlYmE4Zjg2Zjk1MjQwZjoNCg0KICBMaW51eCA0LjEyLXJjNCAoMjAx Ny0wNi0wNCAxNjo0Nzo0MyAtMDcwMCkNCg0KYXJlIGF2YWlsYWJsZSBpbiB0aGUgZ2l0IHJlcG9z aXRvcnkgYXQ6DQoNCiAgZ2l0Oi8vZ2l0LmxpbnV4LW5mcy5vcmcvcHJvamVjdHMvdHJvbmRteS9s aW51eC1uZnMuZ2l0IHRhZ3MvbmZzLWZvci00LjEyLTMNCg0KZm9yIHlvdSB0byBmZXRjaCBjaGFu Z2VzIHVwIHRvIDJlMzFiNGNiODk1YWU3OGRiMzFkZmZiODYwY2QyNTVkODZjNjU2MWM6DQoNCiAg TkZTdjQuMTogbmZzNF9jYWxsYmFja19mcmVlX3Nsb3QoKSBjYW5ub3QgY2FsbCBuZnM0X3Nsb3Rf dGJsX2RyYWluX2NvbXBsZXRlKCkgKDIwMTctMDYtMjcgMjI6MjY6MjMgLTA0MDApDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCk5GUyBjbGllbnQgYnVnZml4ZXMgZm9yIExpbnV4IDQuMTINCg0KQnVnZml4ZXMgaW5jbHVk ZToNCg0KLSBTdGFibGUgZml4IGZvciBleGNsdXNpdmUgY3JlYXRlIGlmIHRoZSBzZXJ2ZXIgc3Vw cG9ydHMgdGhlIHVtYXNrIGF0dHJpYnV0ZQ0KLSBUcnVua2luZyBkZXRlY3Rpb24gc2hvdWxkIGhh bmRsZSBFUkVTVEFSVFNZUy9FSU5UUg0KLSBTdGFibGUgZml4IGZvciBhIHJhY2UgaW4gdGhlIExB WU9VVEdFVCBmdW5jdGlvbg0KLSBTdGFibGUgZml4IHRvIHJldmVydCAibmZzX3JlbmFtZSgpIGhh bmRsZSAtRVJFU1RBUlRTWVMgZGVudHJ5IGxlZnQgYmVoaW5kIg0KLSBuZnM0X2NhbGxiYWNrX2Zy ZWVfc2xvdCgpIGNhbm5vdCBjYWxsIG5mczRfc2xvdF90YmxfZHJhaW5fY29tcGxldGUoKQ0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpCZW5qYW1pbiBDb2RkaW5ndG9uICgyKToNCiAgICAgIE5GU3Y0LjI6IERvbid0IHNl bmQgbW9kZSBhZ2FpbiBpbiBwb3N0LUVYQ0xVU0lWRTRfMSBTRVRBVFRSIHdpdGggdW1hc2sNCiAg ICAgIFJldmVydCAiTkZTOiBuZnNfcmVuYW1lKCkgaGFuZGxlIC1FUkVTVEFSVFNZUyBkZW50cnkg bGVmdCBiZWhpbmQiDQoNClRyb25kIE15a2xlYnVzdCAoMyk6DQogICAgICBORlM6IFRydW5raW5n IGRldGVjdGlvbiBzaG91bGQgaGFuZGxlIEVSRVNUQVJUU1lTL0VJTlRSDQogICAgICBORlN2NC4x OiBGaXggYSByYWNlIGluIG5mczRfcHJvY19sYXlvdXRnZXQNCiAgICAgIE5GU3Y0LjE6IG5mczRf Y2FsbGJhY2tfZnJlZV9zbG90KCkgY2Fubm90IGNhbGwgbmZzNF9zbG90X3RibF9kcmFpbl9jb21w bGV0ZSgpDQoNCiBmcy9uZnMvY2FsbGJhY2tfeGRyLmMgfCAgMSAtDQogZnMvbmZzL2Rpci5jICAg ICAgICAgIHwgNTEgKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogZnMvbmZzL25mczRwcm9jLmMgICAgIHwgIDUgKysrLS0NCiBmcy9uZnMvbmZzNHN0 YXRlLmMgICAgfCAgMiArKw0KIDQgZmlsZXMgY2hhbmdlZCwgMjkgaW5zZXJ0aW9ucygrKSwgMzAg ZGVsZXRpb25zKC0pDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWlu dGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K ^ permalink raw reply [flat|nested] 20+ messages in thread
* [GIT PULL] Please pull NFS client fixes for 4.12 @ 2017-06-28 14:19 ` Trond Myklebust 0 siblings, 0 replies; 20+ messages in thread From: Trond Myklebust @ 2017-06-28 14:19 UTC (permalink / raw) To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org Hi Linus, The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f: Linux 4.12-rc4 (2017-06-04 16:47:43 -0700) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.12-3 for you to fetch changes up to 2e31b4cb895ae78db31dffb860cd255d86c6561c: NFSv4.1: nfs4_callback_free_slot() cannot call nfs4_slot_tbl_drain_complete() (2017-06-27 22:26:23 -0400) ---------------------------------------------------------------- NFS client bugfixes for Linux 4.12 Bugfixes include: - Stable fix for exclusive create if the server supports the umask attribute - Trunking detection should handle ERESTARTSYS/EINTR - Stable fix for a race in the LAYOUTGET function - Stable fix to revert "nfs_rename() handle -ERESTARTSYS dentry left behind" - nfs4_callback_free_slot() cannot call nfs4_slot_tbl_drain_complete() ---------------------------------------------------------------- Benjamin Coddington (2): NFSv4.2: Don't send mode again in post-EXCLUSIVE4_1 SETATTR with umask Revert "NFS: nfs_rename() handle -ERESTARTSYS dentry left behind" Trond Myklebust (3): NFS: Trunking detection should handle ERESTARTSYS/EINTR NFSv4.1: Fix a race in nfs4_proc_layoutget NFSv4.1: nfs4_callback_free_slot() cannot call nfs4_slot_tbl_drain_complete() fs/nfs/callback_xdr.c | 1 - fs/nfs/dir.c | 51 ++++++++++++++++++++++++--------------------------- fs/nfs/nfs4proc.c | 5 +++-- fs/nfs/nfs4state.c | 2 ++ 4 files changed, 29 insertions(+), 30 deletions(-) -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-06-28 14:19 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-10 16:47 [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust 2017-05-10 16:47 ` Trond Myklebust 2017-05-10 20:06 ` Linus Torvalds 2017-05-11 7:53 ` Nikolay Borisov 2017-05-11 7:59 ` Michal Hocko 2017-05-11 12:16 ` Trond Myklebust 2017-05-11 12:16 ` Trond Myklebust 2017-05-11 12:26 ` Michal Hocko 2017-05-11 12:45 ` Trond Myklebust 2017-05-11 12:45 ` Trond Myklebust 2017-05-11 12:56 ` Michal Hocko 2017-05-11 13:10 ` Trond Myklebust 2017-05-11 13:10 ` Trond Myklebust 2017-05-11 13:27 ` Michal Hocko 2017-05-16 15:15 ` Jonathan Corbet 2017-05-11 13:41 ` Trond Myklebust 2017-05-11 13:41 ` Trond Myklebust 2017-05-11 13:54 ` Michal Hocko -- strict thread matches above, loose matches on Subject: below -- 2017-06-28 14:19 Trond Myklebust 2017-06-28 14:19 ` Trond Myklebust
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.