From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-194.mimecast.com ([63.128.21.194]:23912 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932375AbdEKMpH (ORCPT ); Thu, 11 May 2017 08:45:07 -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 12:45:00 +0000 Message-ID: <1494506698.3207.3.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> In-Reply-To: <20170511122613.GJ26782@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932428AbdEKMpJ (ORCPT ); Thu, 11 May 2017 08:45:09 -0400 Received: from us-smtp-delivery-194.mimecast.com ([63.128.21.194]:45035 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932366AbdEKMpH (ORCPT ); Thu, 11 May 2017 08:45:07 -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/6AgAABmoCAAEfrgIAAArGAgAAFPQA= Date: Thu, 11 May 2017 12:45:00 +0000 Message-ID: <1494506698.3207.3.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> In-Reply-To: <20170511122613.GJ26782@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;MWHPR11MB1357;7:Qzu2R43syeaw+bJ0xhU4mqgZV/jiazOM9xsr1Y1v/61wR+wim377vxNDepb4nW3sGcNTavViJzpkDRcO/0a5SQ8lB/jt6LwzU7MLCdSCrHUUK0hWuNPnDYPRzBmB2U7xLmevVptffaQkFziE/7SEjhO/4CLWQIlflIcr3n0/3aYXfYQbRm+wEE1Gusuj/hSyQopTZ55HG/hP1zAX9EaUMsrjoe4RtAZF3mXZYzuxkHrePg02Vo6xSHj9ETQi/EH1bMvxBYUFMbkXF94OH5gjK53+KH10PARiSslFJwcALgLYlLJdpCfYn0cybZ4FBYP3LK2lLxZlzum3lPRXQGgj9g==;20:9cq8h+8/HF7VzdFNcAiLDvXF1WXD7es69LSgerV+/fUHq9AzXsQ0x9qFX55dLJpqYsfRN2j38fC3YZVsAQG7OrMUe5xWZ9K3l5NIuOpWft6mpWwhGNw5uq7KY63SVrVEj3UH3Uiqyog+FWsZ1PcZ50IZ9aWXylIR8tL5BdPh2Sk= x-ms-office365-filtering-correlation-id: efbcd1f2-4138-401d-18c1-08d4986b89fc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201702281549075);SRVR:MWHPR11MB1357; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123564025)(6043046)(6072148);SRVR:MWHPR11MB1357;BCL:0;PCL:0;RULEID:;SRVR:MWHPR11MB1357; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(377424004)(24454002)(229853002)(6512007)(54906002)(2900100001)(110136004)(2501003)(38730400002)(99286003)(6916009)(50986999)(76176999)(36756003)(305945005)(5660300001)(7736002)(2950100002)(478600001)(5640700003)(86362001)(6246003)(66066001)(6436002)(2906002)(103116003)(33646002)(93886004)(4326008)(53546009)(3280700002)(77096006)(3846002)(3660700001)(122556002)(25786009)(8676002)(39060400002)(53936002)(1730700003)(6486002)(189998001)(54356999)(81166006)(6506006)(6116002)(102836003)(2351001)(8936002)(31884003);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR11MB1357;H:MWHPR11MB1359.namprd11.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <2A938B3885B76F43857FC52484982C2D@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2017 12:45:00.7812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1357 X-MC-Unique: 3GVqK4ZVN2y3mXum73o6-Q-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 v4BCjOpg028766 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