From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932590AbdEKMQp (ORCPT ); Thu, 11 May 2017 08:16:45 -0400 Received: from us-smtp-delivery-194.mimecast.com ([63.128.21.194]:59393 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754911AbdEKMQn (ORCPT ); Thu, 11 May 2017 08:16:43 -0400 From: Trond Myklebust To: "mhocko@kernel.org" , "n.borisov.lkml@gmail.com" CC: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-nfs@vger.kernel.org" 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/6AgAABmoCAAEfrgA== Date: Thu, 11 May 2017 12:16:37 +0000 Message-ID: <1494504995.3207.1.camel@primarydata.com> References: <1494434821.4764.1.camel@primarydata.com> <20170511075910.GD26782@dhcp22.suse.cz> In-Reply-To: <20170511075910.GD26782@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:B8VMZEX73epNB92wXtCvJ0o8gt0KwjhZHedkRT0UlVvp0jKbw0VkJnXUml4snzZzGUqeIz7gb0yn/EDKE+3VOLJA1zWXDKFXlK86mf5f3WGpcAprDK3auzVfNz2ImNE1QvCY0U/a77yl8ldpmx/vmNGB6tsWU1uLXe+R6tFgYl8y3/Zs9QW2bxa2VEW1vsKxn5kXzhb7SbAww134CUfIos+3fFGPVeqoerkOzhnfYe09k7GBPFNufxdOk444UmE9MHd9t6Wmqb/kXHbPe7emepzzwi7rOOpgwgPVW7jzFGYxKXocLO4Kbe4gA3XzifRPefcIsqQBUPG/Ay20YnRZrQ==;20:f5lCiYLCcRew5SsJ1FPYQKSEVqn5L2yr6kCqmFom7/UIohrqpmh4kXXSygw52+XekWxCAK2u/EDmqoCheaALJfMULuy6i43ksO7t1KrbF1U3jyqckLpvBK2Gdl98bV9ppGaU5YSTDm2gUsdWEJBwj1YRKb7SsNOu1bZLUaz5pM4= x-ms-office365-filtering-correlation-id: 43d4dc90-9c71-46c1-b616-08d4986792a6 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)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123560025)(20161123555025)(6072148)(6043046);SRVR:MWHPR11MB1358;BCL:0;PCL:0;RULEID:;SRVR:MWHPR11MB1358; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39410400002)(39450400003)(39830400002)(24454002)(377424004)(38730400002)(229853002)(3660700001)(39060400002)(122556002)(3846002)(102836003)(6116002)(6512007)(99286003)(6506006)(103116003)(6436002)(478600001)(6486002)(77096006)(66066001)(2906002)(3280700002)(6246003)(2501003)(86362001)(53936002)(81166006)(8676002)(54906002)(25786009)(53546009)(305945005)(7736002)(2950100002)(33646002)(189998001)(76176999)(54356999)(50986999)(5660300001)(4326008)(36756003)(8936002)(2900100001)(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: MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2017 12:16:37.2832 (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: v6WbjWGRODyyoznOQ5558w-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 v4BCGnh7025861 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