From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-194.mimecast.com ([216.205.24.194]:53257 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755093AbdEKNKU (ORCPT ); Thu, 11 May 2017 09:10:20 -0400 From: Trond Myklebust To: "mhocko@kernel.org" CC: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "n.borisov.lkml@gmail.com" Subject: Re: [GIT PULL] Please pull NFS client fixes for 4.12 Date: Thu, 11 May 2017 13:10:03 +0000 Message-ID: <1494508201.3207.5.camel@primarydata.com> References: <1494434821.4764.1.camel@primarydata.com> <20170511075910.GD26782@dhcp22.suse.cz> <1494504995.3207.1.camel@primarydata.com> <20170511122613.GJ26782@dhcp22.suse.cz> <1494506698.3207.3.camel@primarydata.com> <20170511125612.GK26782@dhcp22.suse.cz> In-Reply-To: <20170511125612.GK26782@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932223AbdEKNKY (ORCPT ); Thu, 11 May 2017 09:10:24 -0400 Received: from us-smtp-delivery-194.mimecast.com ([216.205.24.194]:31154 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755144AbdEKNKU (ORCPT ); Thu, 11 May 2017 09:10:20 -0400 From: Trond Myklebust To: "mhocko@kernel.org" CC: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "n.borisov.lkml@gmail.com" Subject: Re: [GIT PULL] Please pull NFS client fixes for 4.12 Thread-Topic: [GIT PULL] Please pull NFS client fixes for 4.12 Thread-Index: AQHSya0NrD4QrM982UyDRv5+dS7+KaHuw/6AgAABmoCAAEfrgIAAArGAgAAFPQCAAAMjAIAAA92A Date: Thu, 11 May 2017 13:10:03 +0000 Message-ID: <1494508201.3207.5.camel@primarydata.com> References: <1494434821.4764.1.camel@primarydata.com> <20170511075910.GD26782@dhcp22.suse.cz> <1494504995.3207.1.camel@primarydata.com> <20170511122613.GJ26782@dhcp22.suse.cz> <1494506698.3207.3.camel@primarydata.com> <20170511125612.GK26782@dhcp22.suse.cz> In-Reply-To: <20170511125612.GK26782@dhcp22.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.49.162.121] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;MWHPR11MB1358;7:x/XaJvrLC3I8SdPN0cXo6Z0iwydos7nV1RpppPUI5UKI7sIUF1Ui6b8kgeG/ajLr2svCNJva53R17FUfuRbJlC/deJ28E8EQxn5sVLKdiGjLmXl99BgiVqBd6nbiY5f6sSLgkLkOhkOHoZjBtshpVEZ/o32d6CShBbaO5Jynw7kvYdGbv84zkvenrZ30MYwCXDz/Uog/bwvETrwKjIy9ZnO8UKqlt2ikMuzi0+cZJ6cd+iYgX5mDtteprDezcM1iY0wpyzQXjvgfV+z7ERmLYz9HE/4sJm130HMNdvIVhKkYYpvjM19mUAYsWWBD9/FBwJ9xkGIcviaEYMBOtoim5A==;20:YApemRLno9xhIE6lWAN9GtF4VZ5GwN2iP1EtQAZQ/R10+GlISFDHkXaOITglTe6gi3II3AFH4RSqju/wkwiKuzuA+XAbUzdgDLxmjAtHJcYB2URdNZ6jOexhujUPu256My3vMgHTBIjpvvLsbqGb/LF+UsIfDAZSZ/gQsfVsKjg= x-ms-office365-filtering-correlation-id: 9f24114a-fec3-4dce-5fb2-08d4986f09ab x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075);SRVR:MWHPR11MB1358; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148)(6043046);SRVR:MWHPR11MB1358;BCL:0;PCL:0;RULEID:;SRVR:MWHPR11MB1358; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39830400002)(24454002)(377424004)(110136004)(229853002)(38730400002)(3660700001)(39060400002)(99286003)(102836003)(3846002)(122556002)(6116002)(6512007)(6506006)(5640700003)(103116003)(6436002)(478600001)(6486002)(77096006)(66066001)(2906002)(3280700002)(6246003)(2501003)(86362001)(53936002)(1730700003)(93886004)(8676002)(54906002)(25786009)(53546009)(7736002)(305945005)(6916009)(2950100002)(33646002)(189998001)(54356999)(50986999)(5660300001)(76176999)(4326008)(36756003)(2900100001)(8936002)(2351001)(81166006)(31884003);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR11MB1358;H:MWHPR11MB1359.namprd11.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <14B1E532D80EA148A120E31BBB4A796C@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2017 13:10:03.5128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1358 X-MC-Unique: rfRzvWjBOoCxN3Gc29kJoA-1 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4BDAdqa002575 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