From: Jonathan Corbet <corbet@lwn.net> To: Michal Hocko <mhocko@kernel.org> Cc: Dave Chinner <david@fromorbit.com>, Randy Dunlap <rdunlap@infradead.org>, Mike Rapoport <rppt@linux.vnet.ibm.com>, LKML <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.com> Subject: Re: [PATCH v2] doc: document scope NOFS, NOIO APIs Date: Tue, 29 May 2018 05:51:58 -0600 [thread overview] Message-ID: <20180529055158.0170231e@lwn.net> (raw) In-Reply-To: <20180529082644.26192-1-mhocko@kernel.org> On Tue, 29 May 2018 10:26:44 +0200 Michal Hocko <mhocko@kernel.org> 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. 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. Thanks, jon --- docs: Use the kerneldoc comments for memalloc_no*() Now that we have kerneldoc comments for memalloc_no{fs,io}_{save_restore}(), go ahead and pull them into the docs. Signed-off-by: Jonathan Corbet <corbet@lwn.net> --- Documentation/core-api/gfp_mask-from-fs-io.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst index 2dc442b04a77..e0df8f416582 100644 --- a/Documentation/core-api/gfp_mask-from-fs-io.rst +++ b/Documentation/core-api/gfp_mask-from-fs-io.rst @@ -33,6 +33,11 @@ section from a filesystem or I/O point of view. Any allocation from that scope will inherently drop __GFP_FS respectively __GFP_IO from the given mask so no memory allocation can recurse back in the FS/IO. +.. kernel-doc:: include/linux/sched/mm.h + :functions: memalloc_nofs_save memalloc_nofs_restore +.. kernel-doc:: include/linux/sched/mm.h + :functions: memalloc_noio_save memalloc_noio_restore + FS/IO code then simply calls the appropriate save function before any critical section with respect to the reclaim is started - e.g. lock shared with the reclaim context or when a transaction context -- 2.14.3
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Corbet <corbet@lwn.net> To: Michal Hocko <mhocko@kernel.org> Cc: Dave Chinner <david@fromorbit.com>, Randy Dunlap <rdunlap@infradead.org>, Mike Rapoport <rppt@linux.vnet.ibm.com>, LKML <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko <mhocko@suse.com> Subject: Re: [PATCH v2] doc: document scope NOFS, NOIO APIs Date: Tue, 29 May 2018 05:51:58 -0600 [thread overview] Message-ID: <20180529055158.0170231e@lwn.net> (raw) In-Reply-To: <20180529082644.26192-1-mhocko@kernel.org> On Tue, 29 May 2018 10:26:44 +0200 Michal Hocko <mhocko@kernel.org> 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. 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. Thanks, jon --- docs: Use the kerneldoc comments for memalloc_no*() Now that we have kerneldoc comments for memalloc_no{fs,io}_{save_restore}(), go ahead and pull them into the docs. Signed-off-by: Jonathan Corbet <corbet@lwn.net> --- Documentation/core-api/gfp_mask-from-fs-io.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst index 2dc442b04a77..e0df8f416582 100644 --- a/Documentation/core-api/gfp_mask-from-fs-io.rst +++ b/Documentation/core-api/gfp_mask-from-fs-io.rst @@ -33,6 +33,11 @@ section from a filesystem or I/O point of view. Any allocation from that scope will inherently drop __GFP_FS respectively __GFP_IO from the given mask so no memory allocation can recurse back in the FS/IO. +.. kernel-doc:: include/linux/sched/mm.h + :functions: memalloc_nofs_save memalloc_nofs_restore +.. kernel-doc:: include/linux/sched/mm.h + :functions: memalloc_noio_save memalloc_noio_restore + FS/IO code then simply calls the appropriate save function before any critical section with respect to the reclaim is started - e.g. lock shared with the reclaim context or when a transaction context -- 2.14.3
next prev parent reply other threads:[~2018-05-29 11:52 UTC|newest] Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-24 16:27 vmalloc with GFP_NOFS Michal Hocko 2018-04-24 16:27 ` [Cluster-devel] " Michal Hocko 2018-04-24 16:27 ` Michal Hocko 2018-04-24 16:27 ` Michal Hocko 2018-04-24 16:46 ` Mikulas Patocka 2018-04-24 16:46 ` [Cluster-devel] " Mikulas Patocka 2018-04-24 16:46 ` Mikulas Patocka 2018-04-24 16:55 ` Michal Hocko 2018-04-24 16:55 ` [Cluster-devel] " Michal Hocko 2018-04-24 16:55 ` Michal Hocko 2018-04-24 17:05 ` Mikulas Patocka 2018-04-24 17:05 ` [Cluster-devel] " Mikulas Patocka 2018-04-24 17:05 ` Mikulas Patocka 2018-04-24 18:35 ` Theodore Y. Ts'o 2018-04-24 18:35 ` [Cluster-devel] " Theodore Y. Ts'o 2018-04-24 18:35 ` Theodore Y. Ts'o 2018-04-24 19:25 ` Michal Hocko 2018-04-24 19:25 ` [Cluster-devel] " Michal Hocko 2018-04-24 19:25 ` Michal Hocko 2018-05-09 13:42 ` Michal Hocko 2018-05-09 13:42 ` [Cluster-devel] " Michal Hocko 2018-05-09 13:42 ` Michal Hocko 2018-05-09 14:13 ` David Sterba 2018-05-09 14:13 ` [Cluster-devel] " David Sterba 2018-05-09 14:13 ` David Sterba 2018-05-09 15:13 ` Darrick J. Wong 2018-05-09 15:13 ` [Cluster-devel] " Darrick J. Wong 2018-05-09 15:13 ` Darrick J. Wong 2018-05-09 16:24 ` Mike Rapoport 2018-05-09 16:24 ` [Cluster-devel] " Mike Rapoport 2018-05-09 16:24 ` Mike Rapoport 2018-05-09 21:06 ` Michal Hocko 2018-05-09 21:06 ` [Cluster-devel] " Michal Hocko 2018-05-09 21:06 ` Michal Hocko 2018-05-09 21:04 ` Michal Hocko 2018-05-09 21:04 ` [Cluster-devel] " Michal Hocko 2018-05-09 21:04 ` Michal Hocko 2018-05-09 22:02 ` Darrick J. Wong 2018-05-09 22:02 ` [Cluster-devel] " Darrick J. Wong 2018-05-09 22:02 ` Darrick J. Wong 2018-05-10 5:58 ` Michal Hocko 2018-05-10 5:58 ` [Cluster-devel] " Michal Hocko 2018-05-10 5:58 ` Michal Hocko 2018-05-10 7:18 ` Michal Hocko 2018-05-10 7:18 ` [Cluster-devel] " Michal Hocko 2018-05-10 7:18 ` Michal Hocko 2018-05-24 11:43 ` [PATCH] doc: document scope NOFS, NOIO APIs Michal Hocko 2018-05-24 11:43 ` Michal Hocko 2018-05-24 14:33 ` Shakeel Butt 2018-05-24 14:47 ` Michal Hocko 2018-05-24 16:37 ` Randy Dunlap 2018-05-25 7:52 ` Michal Hocko 2018-05-28 7:21 ` Nikolay Borisov 2018-05-29 8:22 ` Michal Hocko 2018-05-28 11:32 ` Vlastimil Babka 2018-05-24 20:52 ` Jonathan Corbet 2018-05-24 20:52 ` Jonathan Corbet 2018-05-25 8:11 ` Michal Hocko 2018-05-24 22:17 ` Dave Chinner 2018-05-24 23:25 ` Theodore Y. Ts'o 2018-05-25 8:16 ` Michal Hocko 2018-05-27 12:47 ` Mike Rapoport 2018-05-28 9:21 ` Michal Hocko 2018-05-28 16:10 ` Randy Dunlap 2018-05-29 8:21 ` Michal Hocko 2018-05-27 23:48 ` Dave Chinner 2018-05-28 9:19 ` Michal Hocko 2018-05-28 22:32 ` Dave Chinner 2018-05-29 8:18 ` Michal Hocko 2018-05-29 8:26 ` [PATCH v2] " Michal Hocko 2018-05-29 8:26 ` Michal Hocko 2018-05-29 10:22 ` Dave Chinner 2018-05-29 11:50 ` Mike Rapoport 2018-05-29 11:51 ` Jonathan Corbet [this message] 2018-05-29 11:51 ` Jonathan Corbet 2018-05-29 12:37 ` Michal Hocko 2018-07-17 12:49 ` vmalloc with GFP_NOFS Michal Hocko 2018-07-17 12:49 ` [Cluster-devel] " Michal Hocko 2018-07-17 12:49 ` Michal Hocko 2018-04-24 19:03 ` Richard Weinberger 2018-04-24 19:03 ` [Cluster-devel] " Richard Weinberger 2018-04-24 19:03 ` Richard Weinberger 2018-04-24 19:28 ` Michal Hocko 2018-04-24 19:28 ` [Cluster-devel] " Michal Hocko 2018-04-24 19:28 ` Michal Hocko 2018-04-24 22:18 ` Richard Weinberger 2018-04-24 22:18 ` [Cluster-devel] " Richard Weinberger 2018-04-24 22:18 ` Richard Weinberger 2018-04-24 23:09 ` Michal Hocko 2018-04-24 23:09 ` [Cluster-devel] " Michal Hocko 2018-04-24 23:09 ` Michal Hocko 2018-04-24 23:17 ` Mikulas Patocka 2018-04-24 23:17 ` [Cluster-devel] " Mikulas Patocka 2018-04-24 23:17 ` Mikulas Patocka 2018-04-24 23:25 ` Michal Hocko 2018-04-24 23:25 ` [Cluster-devel] " Michal Hocko 2018-04-24 23:25 ` Michal Hocko 2018-04-25 12:43 ` Mikulas Patocka 2018-04-25 12:43 ` [Cluster-devel] " Mikulas Patocka 2018-04-25 12:43 ` Mikulas Patocka 2018-04-25 14:45 ` Michal Hocko 2018-04-25 14:45 ` [Cluster-devel] " Michal Hocko 2018-04-25 14:45 ` Michal Hocko 2018-04-25 15:25 ` Mikulas Patocka 2018-04-25 15:25 ` [Cluster-devel] " Mikulas Patocka 2018-04-25 15:25 ` Mikulas Patocka 2018-04-25 16:56 ` Michal Hocko 2018-04-25 16:56 ` [Cluster-devel] " Michal Hocko 2018-04-25 16:56 ` Michal Hocko 2018-07-17 12:47 ` Michal Hocko 2018-07-17 12:47 ` [Cluster-devel] " Michal Hocko 2018-07-17 12:47 ` Michal Hocko 2018-04-24 19:05 ` Richard Weinberger 2018-04-24 19:05 ` [Cluster-devel] " Richard Weinberger 2018-04-24 19:05 ` Richard Weinberger 2018-04-24 19:10 ` Richard Weinberger 2018-04-24 19:10 ` [Cluster-devel] " Richard Weinberger 2018-04-24 19:10 ` Richard Weinberger 2018-04-24 19:26 ` Steven Whitehouse 2018-04-24 19:26 ` [Cluster-devel] " Steven Whitehouse 2018-04-24 19:26 ` Steven Whitehouse 2018-04-24 20:09 ` Michal Hocko 2018-04-24 20:09 ` [Cluster-devel] " Michal Hocko 2018-04-24 20:09 ` Michal Hocko 2018-07-17 12:50 ` Michal Hocko 2018-07-17 12:50 ` [Cluster-devel] " Michal Hocko 2018-07-17 12:50 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180529055158.0170231e@lwn.net \ --to=corbet@lwn.net \ --cc=david@fromorbit.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=mhocko@suse.com \ --cc=rdunlap@infradead.org \ --cc=rppt@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.