Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3337505imm; Tue, 29 May 2018 05:38:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp6hCcdt6IigfIvF03P3ECQ52GM2An+nok/pJE0W5ihFu1QaDb2sem+irPmGefYmQd5IRWf X-Received: by 2002:a65:61c8:: with SMTP id j8-v6mr13661454pgv.370.1527597506694; Tue, 29 May 2018 05:38:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527597506; cv=none; d=google.com; s=arc-20160816; b=fijSNHyA9BGUmwqEKhanq5wQCCRvyozLiWVPejaWsIefQ3kpQsVXiaayTFhMhl5z5s pWz4lOBwPqnO2peSu5x1v2p1APWs4AevojSLtmpWqJ8aqS+hOCQLRV+96beeQtTPVQ6D tsGlGvOtrl8mJmRET+mkUTthEfpODbXLNvTLzQi9IpZ1793U8rKlqTj/8H6cyL8aQd+k 0cCoZ0umE6qcNCOXR6FAX/uXtiLiIiwH7HBo71XRloEIQQ+2OzvpW6UymoCGgGzxL+0v 83rpBEVR8t24dAd5XBI+dgr1cn8CLaIWo2TbjTB2JnJ1SdKLWLI05U7gOsizJiOFP/Vm hB3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=RkULy9NLL0ZyuRiFeomhXbDPsbnFyfJXrM3ohXLmLfE=; b=CLAS/KBJF72hZBVbeNmsjYzd5cJpNAi72sK9TEc+LxPxPJUuE8Q0kVxxKzpH2wg9+B kJnZDf2FH3JPm0wRG2EpGxRi5vPt9Fyr18FPV+3993U4J3vBEm5QcEOuSCP9mmELFGFd YaJexeFPjJYeuqjfF2peP46IKIEVkjEv6X5XSU1ulrRzRudQyq60+b7mdbsLg8B9zI9t X5c9II8ByK6U+SPhl6qqQ1A4J0cU79dmYnyPcPq3X13TkwJOvitj8jKZ35vi/LJptOfQ sWiXpoxhN2Cz82wBUekHww4hY54+XOt0drMEcCOUzse0cRWh0gCYmXYMcnVybLIKgvi9 O95A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2-v6si2445680pli.6.2018.05.29.05.38.12; Tue, 29 May 2018 05:38:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934178AbeE2MhL (ORCPT + 99 others); Tue, 29 May 2018 08:37:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:34785 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933778AbeE2MhH (ORCPT ); Tue, 29 May 2018 08:37:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A9A55AF2D; Tue, 29 May 2018 12:37:05 +0000 (UTC) Date: Tue, 29 May 2018 14:37:04 +0200 From: Michal Hocko To: Jonathan Corbet Cc: Dave Chinner , Randy Dunlap , Mike Rapoport , LKML , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] doc: document scope NOFS, NOIO APIs Message-ID: <20180529123704.GT27180@dhcp22.suse.cz> References: <20180524114341.1101-1-mhocko@kernel.org> <20180529082644.26192-1-mhocko@kernel.org> <20180529055158.0170231e@lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529055158.0170231e@lwn.net> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 29-05-18 05:51:58, Jonathan Corbet wrote: > On Tue, 29 May 2018 10:26:44 +0200 > Michal Hocko wrote: > > > Although the api is documented in the source code Ted has pointed out > > that there is no mention in the core-api Documentation and there are > > people looking there to find answers how to use a specific API. > > So, I still think that this: > > > +The traditional way to avoid this deadlock problem is to clear __GFP_FS > > +respectively __GFP_IO (note the latter implies clearing the first as well) in > > doesn't read the way you intend it to. But we've sent you in more > than enough circles on this already, so I went ahead and applied it; > wording can always be tweaked later. Thanks a lot Jonathan! I am open to any suggestions of course and can follow up with some refinements. Just for the background. The above paragraph is meant to say that: - clearing __GFP_FS is a way to avoid reclaim recursion into filesystems deadlocks - clearing __GFP_IO is a way to avoid reclaim recursion into the IO layer deadlocks - GFP_NOIO implies __GFP_NOFS > You added the kerneldoc comments, but didn't bring them into your new > document. I'm going to tack this on afterward, hopefully nobody will > object. I have to confess I've never studied how the rst and kerneldoc should be interlinked so thanks for the fix up! -- Michal Hocko SUSE Labs