From patchwork Fri May 25 08:11:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10426591 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 BD1B16032C for ; Fri, 25 May 2018 08:12:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AB33E29478 for ; Fri, 25 May 2018 08:12:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9E274295E9; Fri, 25 May 2018 08:12:01 +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=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham 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 B4CC129478 for ; Fri, 25 May 2018 08:12:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C0A26B000D; Fri, 25 May 2018 04:11:59 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 546656B000E; Fri, 25 May 2018 04:11:59 -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 3E7A36B0010; Fri, 25 May 2018 04:11:59 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-wr0-f200.google.com (mail-wr0-f200.google.com [209.85.128.200]) by kanga.kvack.org (Postfix) with ESMTP id D17EB6B000D for ; Fri, 25 May 2018 04:11:58 -0400 (EDT) Received: by mail-wr0-f200.google.com with SMTP id t15-v6so3578227wrm.3 for ; Fri, 25 May 2018 01:11:58 -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=yy9zAi/XBzjPnDUO82nLQD3aUwKCb8i99oCxdujNhhg=; b=AImXQZ9Lo9Pn/N/S/i7dEs60Ec3XpuY3qluh5tPu8Aaa/8iKyo5EKi0S5PYwMz2Sfg 1IqtnoWI+5Ekyma738mQ6eeGyTkpmDXevg9OVTAZhNzzwBcfskBTYnqM0LakByLsgX7Y I6WwQQFfd7PwODNipZpYY6Qu9sdDLajN/KXLDhtHtChiJbzSsKjt9cgD/7sjY/7ydSU7 GO+ocOT2VDNG64uFnUm8MRabmfCVrHE6J214zPRWR+JObJ4eeH+XmCipbzoKCNmRc7Xk sG840X8EvRWa18A7WIE+VR9W7cO6hoMpbvf0oin7DvUWfw4IN1efrU9W2RdnVSyQ09k0 0Xkg== 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: ALKqPwe6dPduTLZesFPZdz6Ekivgi4Wg7QZTD7P2m7P3CTXPnMgdItAN GBeS/oC0JeL13wTlJqQ07Vqj/k3iT11eDX9GrNuwkIoE4qyRhLlK/sXtQ7AlT3iFuLkucfSBCdz fJYOig8wjqETVtDpb8MKPX/pN+GRHtypKWZupC9E104PzOjkS/lSL54QIUx/J4tc= X-Received: by 2002:a50:9606:: with SMTP id y6-v6mr1712182eda.114.1527235918364; Fri, 25 May 2018 01:11:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqUhOzdfcdqj+gJcQVexNLODVz/N2irZGpUO9VC5eZEpzSDYbcWXAg4WLz3s7ITiQIMg2HI X-Received: by 2002:a50:9606:: with SMTP id y6-v6mr1712110eda.114.1527235917378; Fri, 25 May 2018 01:11:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527235917; cv=none; d=google.com; s=arc-20160816; b=mygyGX6/8b5xeLmrThlK2TUNdmrf3Wckf2Pb4R4BSSmfHTyr4HVbi77KNuLkZRMiMz LfLHxaVp8Rx72zp140XVYioTkF09H1aeA0Vr6vitC7wlpRpr3IGhkO5wZCBCtkWJrC0s Yq4z4fhWkpPqBehybd6xmmvI1m04Orxn769wHuS2cBaKNjCMnQaINtAXstGpJdK/Ipma ed4eKlXWteBapqL8E/ZZSUsoSDPc0+ILUGJNMM79wZ8uOnwjX9f4cWAeAZM/vTpI/+X2 doIKbS7YkOYguPLm2gJ94yERsmJFCtK1i2EHDOMHnWM8sEcfL88ckqHWBT0LHzNCkKTq 18IQ== 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=yy9zAi/XBzjPnDUO82nLQD3aUwKCb8i99oCxdujNhhg=; b=sYwP5IAkuJG3j3b77gET3/Qg9IToGHSDNFDkRRQr5fmLwuoR59C6yKaxXvH9fM/gJQ 5hv7pv3zMChgCPdpWEVn69X5ZbQbbcaAcjsx29ls1VZlMtmf/4vUgwwQ/ykBBfilYF0I bvtJVQ6dLeBi4HDaxF/lw9Hkj5AB4103ztmvVlHqTL7CDYh/lcG+D1VYPKR09RaY0oPZ cks/N/sKduyj7EPHuiAAg6v2DfV0pdEFVfUGCPS3M4dsAmHClWCPwT0m4EGUEm4He+ka Al0UIhoWN06pXBK87lmcZgAzD82Cmym8DTW5391KdN8QutF84qGaNipRoZHPTE+OEsH7 Nwqw== 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 5-v6si1917153edx.293.2018.05.25.01.11.57 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 25 May 2018 01:11:57 -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 D7A12ACB2; Fri, 25 May 2018 08:11:55 +0000 (UTC) Date: Fri, 25 May 2018 10:11:55 +0200 From: Michal Hocko To: Jonathan Corbet Cc: 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: <20180525081155.GG11881@dhcp22.suse.cz> References: <20180424183536.GF30619@thunk.org> <20180524114341.1101-1-mhocko@kernel.org> <20180524145202.7d5a55c3@lwn.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180524145202.7d5a55c3@lwn.net> 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 Thu 24-05-18 14:52:02, Jonathan Corbet wrote: > On Thu, 24 May 2018 13:43:41 +0200 > Michal Hocko wrote: > > > From: Michal Hocko > > > > 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. > > > > Cc: "Darrick J. Wong" > > Cc: David Sterba > > Requested-by: "Theodore Y. Ts'o" > > Signed-off-by: Michal Hocko > > --- > > > > Hi Johnatan, > > Ted has proposed this at LSFMM and then we discussed that briefly on the > > mailing list [1]. I received some useful feedback from Darrick and Dave > > which has been (hopefully) integrated. Then the thing fall off my radar > > rediscovering it now when doing some cleanup. Could you take the patch > > please? > > > > [1] http://lkml.kernel.org/r/20180424183536.GF30619@thunk.org > > .../core-api/gfp_mask-from-fs-io.rst | 55 +++++++++++++++++++ > > 1 file changed, 55 insertions(+) > > create mode 100644 Documentation/core-api/gfp_mask-from-fs-io.rst > > So you create the rst file, but don't add it in index.rst; that means it > won't be a part of the docs build and Sphinx will complain. I am not really familiar with how the whole rst thing works. > > +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 > > where a lock *is* taken ? fixed diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index c670a8031786..8a5f48ef16f2 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -25,6 +25,7 @@ Core utilities genalloc errseq printk-formats + gfp_mask-from-fs-io Interfaces for kernel debugging =============================== This? > > > diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst > > new file mode 100644 > > index 000000000000..e8b2678e959b > > --- /dev/null > > +++ b/Documentation/core-api/gfp_mask-from-fs-io.rst > > @@ -0,0 +1,55 @@ > > +================================= > > +GFP masks used from FS/IO context > > +================================= > > + > > +:Date: Mapy, 2018 > > Ah...the wonderful month of Mapy....:) fixed > > +:Author: Michal Hocko > > + > > +Introduction > > +============ > > + > > +Code paths in the filesystem and IO stacks must be careful when > > +allocating memory to prevent recursion deadlocks caused by direct > > +memory reclaim calling back into the FS or IO paths and blocking on > > +already held resources (e.g. locks - most commonly those used for the > > +transaction context). > > + > > +The traditional way to avoid this deadlock problem is to clear __GFP_FS > > +resp. __GFP_IO (note the later implies clearing the first as well) in > > "resp." is indeed a bit terse. Even spelled out as "respectively", though, OK s@resp\.@respectively@g > I'm not sure what the word is intended to mean here. Did you mean "or"? Basically yes. There are two cases here. NOFS and NOIO. The later being a subset of the first. I didn't really want to repeat the whole thing for NOIO. > > > +the gfp mask when calling an allocator. GFP_NOFS resp. GFP_NOIO can be > > Here too. > > > +used as shortcut. It turned out though that above approach has led to > > +abuses when the restricted gfp mask is used "just in case" without a > > +deeper consideration which leads to problems because an excessive use > > +of GFP_NOFS/GFP_NOIO can lead to memory over-reclaim or other memory > > +reclaim issues. > > + > > +New API > > +======== > > + > > +Since 4.12 we do have a generic scope API for both NOFS and NOIO context > > +``memalloc_nofs_save``, ``memalloc_nofs_restore`` resp. ``memalloc_noio_save``, > > +``memalloc_noio_restore`` which allow to mark a scope to be a critical > > +section from the memory reclaim recursion into FS/IO POV. Any allocation > > "from a filesystem or I/O point of view" ? OK > > +from that scope will inherently drop __GFP_FS resp. __GFP_IO from the given > > +mask so no memory allocation can recurse back in the FS/IO. > > Wouldn't it be nice if those functions had kerneldoc comments that could be > pulled in here! :) Most probably yes ;) I thought I've done that but that was probably in a different universe. This probably? diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h index e1f8411e6b80..f49ece8ee37a 100644 --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -166,6 +166,17 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) { } static inline void fs_reclaim_release(gfp_t gfp_mask) { } #endif +/** + * memalloc_noio_save - Marks implicit GFP_NOIO allocation scope. + * + * This functions marks the beginning of the GFP_NOIO allocation scope. + * All further allocations will implicitly drop __GFP_IO flag and so + * they are safe for the IO critical section from the allocation recursion + * point of view. Use memalloc_noio_restore to end the scope with flags + * returned by this function. + * + * This function is safe to be used from any context. + */ static inline unsigned int memalloc_noio_save(void) { unsigned int flags = current->flags & PF_MEMALLOC_NOIO; @@ -173,11 +184,30 @@ static inline unsigned int memalloc_noio_save(void) return flags; } +/** + * memalloc_noio_restore - Ends the implicit GFP_NOIO scope. + * @flags: Flags to restore. + * + * Ends the implicit GFP_NOIO scope started by memalloc_noio_save function. + * Always make sure that that the given flags is the return value from the + * pairing memalloc_noio_save call. + */ static inline void memalloc_noio_restore(unsigned int flags) { current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags; } +/** + * memalloc_nofs_save - Marks implicit GFP_NOFS allocation scope. + * + * This functions marks the beginning of the GFP_NOFS allocation scope. + * All further allocations will implicitly drop __GFP_FS flag and so + * they are safe for the FS critical section from the allocation recursion + * point of view. Use memalloc_nofs_restore to end the scope with flags + * returned by this function. + * + * This function is safe to be used from any context. + */ static inline unsigned int memalloc_nofs_save(void) { unsigned int flags = current->flags & PF_MEMALLOC_NOFS; @@ -185,6 +215,14 @@ static inline unsigned int memalloc_nofs_save(void) return flags; } +/** + * memalloc_nofs_restore - Ends the implicit GFP_NOFS scope. + * @flags: Flags to restore. + * + * Ends the implicit GFP_NOFS scope started by memalloc_nofs_save function. + * Always make sure that that the given flags is the return value from the + * pairing memalloc_nofs_save call. + */ static inline void memalloc_nofs_restore(unsigned int flags) { current->flags = (current->flags & ~PF_MEMALLOC_NOFS) | flags;