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 2/3] stackdepot: use gfp_nested_mask() instead of open coded masking
Date: Tue, 30 Apr 2024 15:28:24 +1000 [thread overview]
Message-ID: <20240430054604.4169568-3-david@fromorbit.com> (raw)
In-Reply-To: <20240430054604.4169568-1-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
The stackdepot code is used by KASAN and lockdep for recoding stack
traces. Both of these track allocation context information, and so
their internal allocations must obey the caller allocation contexts
to avoid generating their own false positive warnings that have
nothing to do with the code they are instrumenting/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 stackdepot allocation masking to use gfp_nested_mask()
to address these issues. gfp_nested_mask() also strips GFP_ZONEMASK
naturally, so that greatly simplifies this code.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
lib/stackdepot.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 68c97387aa54..0bbae49e6177 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -624,15 +624,8 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries,
* we won't be able to do that under the lock.
*/
if (unlikely(can_alloc && !READ_ONCE(new_pool))) {
- /*
- * Zero out zone modifiers, as we don't have specific zone
- * requirements. Keep the flags related to allocation in atomic
- * contexts and I/O.
- */
- alloc_flags &= ~GFP_ZONEMASK;
- alloc_flags &= (GFP_ATOMIC | GFP_KERNEL);
- alloc_flags |= __GFP_NOWARN;
- page = alloc_pages(alloc_flags, DEPOT_POOL_ORDER);
+ page = alloc_pages(gfp_nested_mask(alloc_flags),
+ DEPOT_POOL_ORDER);
if (page)
prealloc = page_address(page);
}
--
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 ` Dave Chinner [this message]
2024-04-30 12:39 ` [PATCH 2/3] stackdepot: use gfp_nested_mask() instead of open coded masking Marco Elver
2024-04-30 5:28 ` [PATCH 3/3] mm/page-owner: " Dave Chinner
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-3-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 NNTP newsgroup(s).