From: Michal Hocko <mhocko@suse.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Yafang Shao <laoar.shao@gmail.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
jack@suse.cz, Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-bcachefs@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: drop PF_MEMALLOC_NORECLAIM
Date: Mon, 26 Aug 2024 21:18:01 +0200 [thread overview]
Message-ID: <ZszU6dTOJYmujMPd@tiehlicka> (raw)
In-Reply-To: <ZszAI7oYsh7FvGgg@casper.infradead.org>
On Mon 26-08-24 18:49:23, Matthew Wilcox wrote:
> On Mon, Aug 26, 2024 at 06:51:55PM +0200, Michal Hocko wrote:
[...]
> > If a plan revert is preferably, I will go with it.
>
> There aren't any other users of PF_MEMALLOC_NOWARN and it definitely
> seems like something you want at a callsite rather than blanket for every
> allocation below this point. We don't seem to have many PF_ flags left,
> so let's not keep it around if there's no immediate plans for it.
Good point. What about this?
---
From 923cd429d4b1a3520c93bcf46611ae74a3158865 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Mon, 26 Aug 2024 21:15:02 +0200
Subject: [PATCH] Revert "mm: introduce PF_MEMALLOC_NORECLAIM,
PF_MEMALLOC_NOWARN"
This reverts commit eab0af905bfc3e9c05da2ca163d76a1513159aa4.
There is no existing user of those flags. PF_MEMALLOC_NOWARN is
dangerous because a nested allocation context can use GFP_NOFAIL which
could cause unexpected failure. Such a code would be hard to maintain
because it could be deeper in the call chain.
PF_MEMALLOC_NORECLAIM has been added even when it was pointed out [1]
that such a allocation contex is inherently unsafe if the context
doesn't fully control all allocations called from this context.
While PF_MEMALLOC_NOWARN is not dangerous the way PF_MEMALLOC_NORECLAIM
is it doesn't have any user and as Matthew has pointed out we are
running out of those flags so better reclaim it without any real users.
[1] https://lore.kernel.org/all/ZcM0xtlKbAOFjv5n@tiehlicka/
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
include/linux/sched.h | 4 ++--
include/linux/sched/mm.h | 17 ++++-------------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f8d150343d42..731ff1078c9e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1657,8 +1657,8 @@ extern struct pid *cad_pid;
* I am cleaning dirty pages from some other bdi. */
#define PF_KTHREAD 0x00200000 /* I am a kernel thread */
#define PF_RANDOMIZE 0x00400000 /* Randomize virtual address space */
-#define PF_MEMALLOC_NORECLAIM 0x00800000 /* All allocation requests will clear __GFP_DIRECT_RECLAIM */
-#define PF_MEMALLOC_NOWARN 0x01000000 /* All allocation requests will inherit __GFP_NOWARN */
+#define PF__HOLE__00800000 0x00800000
+#define PF__HOLE__01000000 0x01000000
#define PF__HOLE__02000000 0x02000000
#define PF_NO_SETAFFINITY 0x04000000 /* Userland is not allowed to meddle with cpus_mask */
#define PF_MCE_EARLY 0x08000000 /* Early kill for mce process policy */
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 91546493c43d..07c4fde32827 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -258,25 +258,16 @@ static inline gfp_t current_gfp_context(gfp_t flags)
{
unsigned int pflags = READ_ONCE(current->flags);
- if (unlikely(pflags & (PF_MEMALLOC_NOIO |
- PF_MEMALLOC_NOFS |
- PF_MEMALLOC_NORECLAIM |
- PF_MEMALLOC_NOWARN |
- PF_MEMALLOC_PIN))) {
+ if (unlikely(pflags & (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS | PF_MEMALLOC_PIN))) {
/*
- * Stronger flags before weaker flags:
- * NORECLAIM implies NOIO, which in turn implies NOFS
+ * NOIO implies both NOIO and NOFS and it is a weaker context
+ * so always make sure it makes precedence
*/
- if (pflags & PF_MEMALLOC_NORECLAIM)
- flags &= ~__GFP_DIRECT_RECLAIM;
- else if (pflags & PF_MEMALLOC_NOIO)
+ if (pflags & PF_MEMALLOC_NOIO)
flags &= ~(__GFP_IO | __GFP_FS);
else if (pflags & PF_MEMALLOC_NOFS)
flags &= ~__GFP_FS;
- if (pflags & PF_MEMALLOC_NOWARN)
- flags |= __GFP_NOWARN;
-
if (pflags & PF_MEMALLOC_PIN)
flags &= ~__GFP_MOVABLE;
}
--
2.46.0
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-08-26 19:18 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 8:47 [PATCH 0/2] get rid of PF_MEMALLOC_NORECLAIM Michal Hocko
2024-08-26 8:47 ` [PATCH 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Michal Hocko
2024-08-26 13:11 ` Matthew Wilcox
2024-08-26 16:48 ` Michal Hocko
2024-08-26 19:39 ` Kent Overstreet
2024-08-26 19:41 ` Matthew Wilcox
2024-08-26 19:42 ` Kent Overstreet
2024-08-26 19:47 ` Matthew Wilcox
2024-08-26 19:54 ` Kent Overstreet
2024-08-26 19:44 ` Kent Overstreet
2024-08-26 19:58 ` Michal Hocko
2024-08-26 20:00 ` Kent Overstreet
2024-08-26 20:27 ` Michal Hocko
2024-08-26 20:43 ` Kent Overstreet
2024-08-26 21:10 ` Kent Overstreet
2024-08-27 6:01 ` Michal Hocko
2024-08-27 6:40 ` Kent Overstreet
2024-08-27 6:58 ` Michal Hocko
2024-08-27 7:05 ` Kent Overstreet
2024-08-27 7:35 ` Michal Hocko
2024-08-26 19:52 ` kernel test robot
2024-08-26 20:53 ` kernel test robot
2024-08-27 2:23 ` kernel test robot
2024-08-27 6:15 ` [PATCH 1/2 v2] " Michal Hocko
2024-08-27 12:29 ` Christoph Hellwig
2024-08-28 4:09 ` Dave Chinner
2024-08-29 10:02 ` Kent Overstreet
2024-08-29 13:12 ` Dave Chinner
2024-08-29 13:22 ` Kent Overstreet
2024-08-29 13:32 ` Kent Overstreet
2024-08-29 14:03 ` Yafang Shao
2024-09-02 0:23 ` Dave Chinner
2024-09-02 1:35 ` Kent Overstreet
2024-09-02 8:41 ` Michal Hocko
2024-09-02 8:52 ` Kent Overstreet
2024-09-02 9:39 ` Michal Hocko
2024-09-02 9:51 ` Kent Overstreet
2024-09-02 14:07 ` Jonathan Corbet
2024-09-04 18:01 ` Shuah Khan
2024-11-20 20:34 ` Kent Overstreet
2024-11-20 21:12 ` Shuah Khan
2024-11-20 21:20 ` Kent Overstreet
2024-11-20 21:37 ` Shuah Khan
2024-11-20 22:21 ` Shuah Khan
2024-11-20 22:39 ` Kent Overstreet
2024-11-20 22:55 ` Kent Overstreet
2024-11-20 23:21 ` Kent Overstreet
2024-11-20 23:47 ` Theodore Ts'o
2024-11-20 23:57 ` Kent Overstreet
2024-11-21 0:10 ` Kent Overstreet
2024-11-21 4:25 ` Christoph Hellwig
2024-11-21 4:53 ` Kent Overstreet
2024-11-21 23:53 ` Shuah Khan
2024-11-22 6:51 ` Kent Overstreet
2024-11-22 12:06 ` Christoph Hellwig
2024-11-21 21:32 ` Martin Steigerwald
2024-11-22 9:47 ` Geert Uytterhoeven
2024-11-21 5:51 ` Kent Overstreet
2024-11-21 8:43 ` review process (was: underalated stuff) Michal Hocko
2024-11-21 9:03 ` Kent Overstreet
2024-11-21 20:17 ` [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Simona Vetter
2024-11-21 21:26 ` Martin Steigerwald
2024-11-22 21:48 ` Dan Williams
2024-11-22 22:02 ` Kent Overstreet
[not found] ` <1592065022.1379875.1732602282945@fidget.co-bxl>
2024-11-26 6:27 ` Dylan
2024-08-29 9:37 ` [PATCH 1/2] " Jan Kara
2024-08-26 8:47 ` [PATCH 2/2] mm: drop PF_MEMALLOC_NORECLAIM Michal Hocko
2024-08-26 13:48 ` Yafang Shao
2024-08-26 16:54 ` Michal Hocko
2024-08-26 13:59 ` Matthew Wilcox
2024-08-26 16:51 ` Michal Hocko
2024-08-26 17:49 ` Matthew Wilcox
2024-08-26 19:18 ` Michal Hocko [this message]
2024-08-26 19:20 ` Matthew Wilcox
2024-08-28 4:11 ` Dave Chinner
2024-08-29 21:45 ` Vlastimil Babka
2024-08-26 19:04 ` Kent Overstreet
2024-08-27 12:29 ` Christoph Hellwig
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=ZszU6dTOJYmujMPd@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=kent.overstreet@linux.dev \
--cc=laoar.shao@gmail.com \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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: link
Be 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.