From patchwork Mon May 28 09:21:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10433535 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 06F2D60327 for ; Mon, 28 May 2018 15:54:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E941128AE1 for ; Mon, 28 May 2018 15:54:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DDABB28B27; Mon, 28 May 2018 15:54:20 +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 7D52028AE1 for ; Mon, 28 May 2018 15:54:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B71106B026E; Mon, 28 May 2018 11:54:18 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id AAD8F6B026F; Mon, 28 May 2018 11:54:18 -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 926146B0270; Mon, 28 May 2018 11:54:18 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f72.google.com (mail-pl0-f72.google.com [209.85.160.72]) by kanga.kvack.org (Postfix) with ESMTP id 429176B026E for ; Mon, 28 May 2018 11:54:18 -0400 (EDT) Received: by mail-pl0-f72.google.com with SMTP id 31-v6so7813627plf.19 for ; Mon, 28 May 2018 08:54:18 -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=p1aH8ZatdS6seNCEx8jw7kCykSqILgIkCjV64lQl7uQ=; b=qeGGkqqLoN1RX5iaaCi9r1YR9aOM6+AWabPdKU2yQKludDmqKs9FOgzgxXJaAFXxll Gk5lJBxQH3KgHGW/jtoZfUSEXXpE8yR/Hoz/SFmrWazpecBhFRLs3cPgCwLQPu4krhkO ROfvgD+ygVEDboQqtjdLY5+hQ5DESbrDocfb+5fhcu3wh9JftRPc5pXyZTKZIu0xncwl kvlvBdouE6wsVDk5egvlDuUroYiqNB/liuG0uy5PsPiiMbkJ5BT72g80KOSgeTIm+Rjz VxwpWu1Gn/tA0vsRpOGySywzMWJtEtN6+xrjVEtTkmgQcex0lJUd2sPH0j6NP3xgKDiQ BDvA== 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: ALKqPwdgCub4UfzOO8q/DlHnQ8TFRE3HlE4P/asdUB8xvRXI9jYrn8VI 8crU0RzKG8ueFRFBSpgv59pV7qN142xnQqlgXJe5jpIvxeD7bXz+CwDm6auUk0x1oKFcdzfdwHx en6q+4ow/ZQdDi9qkvfvQaBWpVB3nK9P12+KvZym3I4xkc61rXvbqe9cP6C7cUX8= X-Received: by 2002:a17:902:683:: with SMTP id 3-v6mr14237059plh.291.1527522857960; Mon, 28 May 2018 08:54:17 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrXYU/gU48yZImjWXnaNv9sSKRgYmAouBq3lxld/esxFkbF8pIZwniBZ/e9thYS03quLNBI X-Received: by 2002:a17:902:683:: with SMTP id 3-v6mr14237022plh.291.1527522857178; Mon, 28 May 2018 08:54:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527522857; cv=none; d=google.com; s=arc-20160816; b=lT0HpZwO2R/n2bsZtrGDmXkyjfP9oARIIhpQk+df9ATu734nzFUdAdTxCMG6lxG/fk CDguPTz75luRLunIPmVEvB3uvta6aMM857rCeAgrrqESIbNxq83ib0vCZGrxO1kkqAnN wVd5IPgtCYt9SU/0ahUBoYqWqFhd6BxGysuJ4l3PQi7lKbyBxRnO3KvMcTvBf1lQYEN6 A6HWEgqHpR1hjyZmFAw5RduKI7Ej91r7MA+2vP9nTemoml4NrdGEdyorxKon68vySnFq TpEl81V7AXPdYVBhH4vCxy5TcAkzyHaEgFMs6YBKJyxq0xXOPODubK7AIXWchqtURHoN CRdw== 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=p1aH8ZatdS6seNCEx8jw7kCykSqILgIkCjV64lQl7uQ=; b=GMeV5zB8eNJjiuMrK2DqN20eelgM/pD1cRKNlgSslVD4nXPYuk+iSuPWPxPUa701Yh Am2auGpIlP82+pN+DB9r50gcHKnV5WtIh7LCD8fK33gLCd2d6EN00incVEWa+93pkoaU XWyNZe7By/aINWOprcWucOod2spoGteikZ6Wz2a06CJLMNxZwFFJZ5XgCWOw5gIeC97q GuX9Wsh6K46J8ir6OTkIwMt+dgit9WfnPAudzvMd3OVfS2By6J8T9yNZ/OIaZI3Wpgci dcrtuUYnMmwA3QrF+1ZA2w9Y3lK/5rXO889VgR392ieXsfR/GdvjKpe+B8GuoDxAl6an YM2A== 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 p15-v6si88684plq.180.2018.05.28.08.54.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 28 May 2018 08:54:17 -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 relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EF6D3AE7C; Mon, 28 May 2018 15:54:13 +0000 (UTC) Date: Mon, 28 May 2018 11:21:38 +0200 From: Michal Hocko To: Mike Rapoport Cc: Dave Chinner , 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: <20180528092138.GI1517@dhcp22.suse.cz> References: <20180424183536.GF30619@thunk.org> <20180524114341.1101-1-mhocko@kernel.org> <20180524221715.GY10363@dastard> <20180525081624.GH11881@dhcp22.suse.cz> <20180527124721.GA4522@rapoport-lnx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180527124721.GA4522@rapoport-lnx> 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 Sun 27-05-18 15:47:22, Mike Rapoport 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 > > Maybe: "The corresponding restore function is called when the lock is > released" This will get rewritten some more based on comments from Dave > > +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. > > so it is safe to call memalloc_noio_save from an existing NOIO or NOFS > scope Here is what I have right now on top diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst index c0ec212d6773..0cff411693ab 100644 --- a/Documentation/core-api/gfp_mask-from-fs-io.rst +++ b/Documentation/core-api/gfp_mask-from-fs-io.rst @@ -34,12 +34,15 @@ 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. - -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. +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 it is safe to call ``memalloc_noio_save`` respectively +``memalloc_noio_restore`` from an existing NOIO or NOFS scope. What about __vmalloc(GFP_NOFS) ==============================