From patchwork Mon May 28 09:19:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10433603 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 799A660327 for ; Mon, 28 May 2018 16:03:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 676172890A for ; Mon, 28 May 2018 16:03:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5C37728A73; Mon, 28 May 2018 16:03:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=2.0 tests=BAYES_00, DATE_IN_PAST_06_12, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EDD8B2890A for ; Mon, 28 May 2018 16:03:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39E236B0008; Mon, 28 May 2018 12:03:51 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 2DA8F6B000A; Mon, 28 May 2018 12:03:51 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E0EE6B000C; Mon, 28 May 2018 12:03:50 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id A09E36B0007 for ; Mon, 28 May 2018 12:03:50 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id q16-v6so7818062pls.15 for ; Mon, 28 May 2018 09:03:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=ECmUcrDRjlF2ydG1A3CPlww0qAlB4XED6t7XWfUGcS4=; b=dC5WsaU1K1JGSEa26z89U51QGFPgFCQXo8bj2UrhFn3b422IWpc1/V0AbiemuRPyN4 loNdkukso7q4EVqZtDBbgDZfq+F44vRa3V5uG1J/oLKcJdysg361yPW71NzPoxe/8JCS mtIZloNjtlQ6qhYSxR2RzhxRgXUmc/VpEKDblbkwcNOqATnsIyR8U5SXhbuckwMlGM87 evscbmQVc2Hut0LXh4Ulub7K4VWxuetXRALn6EBnZ8xx/74QlmOF9aE/15qidylU8vj6 G9fYSZNjgBwChAAKBhCo64ytL5gd5npbRUemo2YmEfUs4aTWocP7Z6T2YUHlI0BvqD1D h1kQ== X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: ALKqPwe2OgBKt5bkWbRni7F425E18LgDL/6a1gly3CJgaNqJXGWTZhem aLaMN5ssBrRBrSqLOEiF6349rZqXlA9c3agnwoqBg/DYBBqynrlGFz6ZAWHhArOHnXlZrNoqryA ei3zefD2SgOEgAWun8rqJfp0IaehuOOjPHyhvk/JSw56xgc1hnKuDc+fB1EiEQnM= X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11-v6mr13974364plb.95.1527523430341; Mon, 28 May 2018 09:03:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpdVzbUrsJv713jYGEK56jTi8JDLlKXuvdhLlISLh6lBrQsmIr/kgbmO7swNYiyuyHqrq/G X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11-v6mr13974330plb.95.1527523429780; Mon, 28 May 2018 09:03:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527523429; cv=none; d=google.com; s=arc-20160816; b=FsrOu+7sWMcg5SAJcVx79iJka7NlMeRaaBcDdazutyCww8Ou1jbvKOXZDYeYaovUAi 4gcq5tF5O2fF3iKw17I3pyT2nfIs1Wogzd+3MPNvFCdCj/7C67zQ8K14ItDO6kTTazCU WZHv7U8VLs+/Gbe5eN49R4ggJBxUew91r+aWFJ8qA8+LbbyLa0UHtEoJ3PGmG86tRbNL tow/672T4P58TBUYc4a2R+Kt8xbN8k3mLUH7BdtQwecaUZbaR6yfKh3ddZIXE2BpZLAS J6aEE1ZEzUYxQvkk5U27YfGc+z/NMYoQEczWrYrXodcbZQmeMr7PZRp9meL4vDhyjvbx etQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=ECmUcrDRjlF2ydG1A3CPlww0qAlB4XED6t7XWfUGcS4=; b=0W1YnPLioKFcjdbbhDxr8vWLp3NvKNeS0X5MCbqEOvbAzhK3QIZ0YvLn5/aNWLILFR if1t+jggEqKRIdbWBKR1q84VmpIjROUBW0oenSciE4jlH5UpBWxycnutiHqyKVAZnDOg qPfxvFmKOTHgkrhWN4tFDjGoUQq2dUPPKMNFll8J6F3ixOFDvk4r5sascCLwbUTZ3w4Y yVJiManOqRJMNOKaOpag6dEVbhpNsAG2CuMtLbEFAupF0g71lt1piwBNTXUZgGslPK7j 2Joj+nid/e+E9dpbXlfx6iFVbsk/JHCAyCIkuxQQWShupsblZuP5jzk8OrhUpRqNvSDg GG9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id b9-v6si30719571pfn.100.2018.05.28.09.03.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 28 May 2018 09:03:49 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 230BEADCC; Mon, 28 May 2018 16:03:46 +0000 (UTC) Date: Mon, 28 May 2018 11:19:23 +0200 From: Michal Hocko To: Dave Chinner Cc: Jonathan Corbet , LKML , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, "Darrick J. Wong" , David Sterba Subject: Re: [PATCH] doc: document scope NOFS, NOIO APIs Message-ID: <20180528091923.GH1517@dhcp22.suse.cz> References: <20180424183536.GF30619@thunk.org> <20180524114341.1101-1-mhocko@kernel.org> <20180524221715.GY10363@dastard> <20180525081624.GH11881@dhcp22.suse.cz> <20180527234854.GF23861@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180527234854.GF23861@dastard> User-Agent: Mutt/1.9.5 (2018-04-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP On Mon 28-05-18 09:48:54, Dave Chinner wrote: > On Fri, May 25, 2018 at 10:16:24AM +0200, Michal Hocko wrote: > > On Fri 25-05-18 08:17:15, Dave Chinner wrote: > > > On Thu, May 24, 2018 at 01:43:41PM +0200, Michal Hocko wrote: > > [...] > > > > +FS/IO code then simply calls the appropriate save function right at the > > > > +layer where a lock taken from the reclaim context (e.g. shrinker) and > > > > +the corresponding restore function when the lock is released. All that > > > > +ideally along with an explanation what is the reclaim context for easier > > > > +maintenance. > > > > > > This paragraph doesn't make much sense to me. I think you're trying > > > to say that we should call the appropriate save function "before > > > locks are taken that a reclaim context (e.g a shrinker) might > > > require access to." > > > > > > I think it's also worth making a note about recursive/nested > > > save/restore stacking, because it's not clear from this description > > > that this is allowed and will work as long as inner save/restore > > > calls are fully nested inside outer save/restore contexts. > > > > Any better? > > > > -FS/IO code then simply calls the appropriate save function right at the > > -layer where a lock taken from the reclaim context (e.g. shrinker) and > > -the corresponding restore function when the lock is released. All that > > -ideally along with an explanation what is the reclaim context for easier > > -maintenance. > > +FS/IO code then simply calls the appropriate save function before any > > +lock shared with the reclaim context is taken. The corresponding > > +restore function when the lock is released. All that ideally along with > > +an explanation what is the reclaim context for easier maintenance. > > + > > +Please note that the proper pairing of save/restore function allows nesting > > +so memalloc_noio_save is safe to be called from an existing NOIO or NOFS scope. > > It's better, but the talk of this being necessary for locking makes > me cringe. XFS doesn't do it for locking reasons - it does it > largely for preventing transaction context nesting, which has all > sorts of problems that cause hangs (e.g. log space reservations > can't be filled) that aren't directly locking related. Yeah, I wanted to not mention locks as much as possible. > i.e we should be talking about using these functions around contexts > where recursion back into the filesystem through reclaim is > problematic, not that "holding locks" is problematic. Locks can be > used as an example of a problematic context, but locks are not the > only recursion issue that require GFP_NOFS allocation contexts to > avoid. agreed. Do you have any suggestion how to add a more abstract wording that would not make head spinning? I've tried the following. Any better? diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst index c0ec212d6773..adac362b2875 100644 --- a/Documentation/core-api/gfp_mask-from-fs-io.rst +++ b/Documentation/core-api/gfp_mask-from-fs-io.rst @@ -34,9 +34,11 @@ scope will inherently drop __GFP_FS respectively __GFP_IO from the given mask so no memory allocation can recurse back in the FS/IO. FS/IO code then simply calls the appropriate save function before any -lock shared with the reclaim context is taken. The corresponding -restore function when the lock is released. All that ideally along with -an explanation what is the reclaim context for easier maintenance. +critical section wrt. the reclaim is started - e.g. lock shared with the +reclaim context or when a transaction context nesting would be possible +via reclaim. The corresponding restore function when the critical +section ends. All that ideally along with an explanation what is +the reclaim context for easier maintenance. Please note that the proper pairing of save/restore function allows nesting so memalloc_noio_save is safe to be called from an existing NOIO or NOFS scope.