From: Dave Chinner <david@fromorbit.com>
To: linux-mm@kvack.org, linux-xfs@vger.kernel.org
Cc: akpm@linux-foundation.org, hch@lst.de, osalvador@suse.de,
elver@google.com, vbabka@suse.cz, andreyknvl@gmail.com
Subject: [PATCH 3/3] mm/page-owner: use gfp_nested_mask() instead of open coded masking
Date: Tue, 30 Apr 2024 15:28:25 +1000 [thread overview]
Message-ID: <20240430054604.4169568-4-david@fromorbit.com> (raw)
In-Reply-To: <20240430054604.4169568-1-david@fromorbit.com>
The page-owner tracking code records stack traces during page
allocation. To do this, it must do a memory allocation for the stack
information from inside an existing memory allocation context. This
internal allocation must obey the high level caller allocation
constraints to avoid generating false positive warnings that have
nothing to do with the code they are instrumenting/tracking (e.g.
through lockdep reclaim state tracking)
We also don't want recording stack traces to deplete emergency
memory reserves - debug code is useless if it creates new issues
that can't be replicated when the debug code is disabled.
Switch the stack tracking allocation masking to use
gfp_nested_mask() to address these issues. gfp_nested_mask()
naturally strips GFP_ZONEMASK, too, which greatly simplifies this
code.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
mm/page_owner.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 742f432e5bf0..55e89c34f0cd 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -168,13 +168,8 @@ static void add_stack_record_to_list(struct stack_record *stack_record,
unsigned long flags;
struct stack *stack;
- /* Filter gfp_mask the same way stackdepot does, for consistency */
- gfp_mask &= ~GFP_ZONEMASK;
- gfp_mask &= (GFP_ATOMIC | GFP_KERNEL);
- gfp_mask |= __GFP_NOWARN;
-
set_current_in_page_owner();
- stack = kmalloc(sizeof(*stack), gfp_mask);
+ stack = kmalloc(sizeof(*stack), gfp_nested_mask(gfp_mask));
if (!stack) {
unset_current_in_page_owner();
return;
--
2.43.0
next prev parent reply other threads:[~2024-04-30 5:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 5:28 [PATCH 0/3] mm: fix nested allocation context filtering Dave Chinner
2024-04-30 5:28 ` [PATCH 1/3] mm: lift gfp_kmemleak_mask() to gfp.h Dave Chinner
2024-04-30 12:39 ` Marco Elver
2024-04-30 5:28 ` [PATCH 2/3] stackdepot: use gfp_nested_mask() instead of open coded masking Dave Chinner
2024-04-30 12:39 ` Marco Elver
2024-04-30 5:28 ` Dave Chinner [this message]
2024-04-30 9:35 ` [PATCH 0/3] mm: fix nested allocation context filtering Christoph Hellwig
2024-04-30 10:06 ` Vlastimil Babka
2024-05-01 8:06 ` Oscar Salvador
2024-05-02 17:05 ` Andrew Morton
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=20240430054604.4169568-4-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=elver@google.com \
--cc=hch@lst.de \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=osalvador@suse.de \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).