From: Andrey Konovalov <andreyknvl@gmail.com>
To: Marco Elver <elver@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Vijayanand Jitta <vjitta@codeaurora.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Imran Khan <imran.f.khan@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux Memory Management List <linux-mm@kvack.org>,
Chris Wilson <chris@chris-wilson.co.uk>,
Jani Nikula <jani.nikula@intel.com>,
Mika Kuoppala <mika.kuoppala@linux.intel.com>,
dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()
Date: Tue, 30 Nov 2021 15:33:41 +0100 [thread overview]
Message-ID: <CA+fCnZdO4OqLqUyCJ6YQbpgAOpDk_BQrUBgP87KQmw7qv7zTZQ@mail.gmail.com> (raw)
In-Reply-To: <20211130095727.2378739-1-elver@google.com>
On Tue, Nov 30, 2021 at 11:14 AM Marco Elver <elver@google.com> wrote:
>
> The non-interrupt portion of interrupt stack traces before interrupt
> entry is usually arbitrary. Therefore, saving stack traces of interrupts
> (that include entries before interrupt entry) to stack depot leads to
> unbounded stackdepot growth.
>
> As such, use of filter_irq_stacks() is a requirement to ensure
> stackdepot can efficiently deduplicate interrupt stacks.
>
> Looking through all current users of stack_depot_save(), none (except
> KASAN) pass the stack trace through filter_irq_stacks() before passing
> it on to stack_depot_save().
>
> Rather than adding filter_irq_stacks() to all current users of
> stack_depot_save(), it became clear that stack_depot_save() should
> simply do filter_irq_stacks().
>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> lib/stackdepot.c | 13 +++++++++++++
> mm/kasan/common.c | 1 -
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index b437ae79aca1..519c7898c7f2 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -305,6 +305,9 @@ EXPORT_SYMBOL_GPL(stack_depot_fetch);
> * (allocates using GFP flags of @alloc_flags). If @can_alloc is %false, avoids
> * any allocations and will fail if no space is left to store the stack trace.
> *
> + * If the stack trace in @entries is from an interrupt, only the portion up to
> + * interrupt entry is saved.
> + *
> * Context: Any context, but setting @can_alloc to %false is required if
> * alloc_pages() cannot be used from the current context. Currently
> * this is the case from contexts where neither %GFP_ATOMIC nor
> @@ -323,6 +326,16 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries,
> unsigned long flags;
> u32 hash;
>
> + /*
> + * If this stack trace is from an interrupt, including anything before
> + * interrupt entry usually leads to unbounded stackdepot growth.
> + *
> + * Because use of filter_irq_stacks() is a requirement to ensure
> + * stackdepot can efficiently deduplicate interrupt stacks, always
> + * filter_irq_stacks() to simplify all callers' use of stackdepot.
> + */
> + nr_entries = filter_irq_stacks(entries, nr_entries);
> +
> if (unlikely(nr_entries == 0) || stack_depot_disable)
> goto fast_exit;
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 8428da2aaf17..efaa836e5132 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -36,7 +36,6 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags, bool can_alloc)
> unsigned int nr_entries;
>
> nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 0);
> - nr_entries = filter_irq_stacks(entries, nr_entries);
> return __stack_depot_save(entries, nr_entries, flags, can_alloc);
> }
>
> --
> 2.34.0.rc2.393.gf8c9666880-goog
>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
prev parent reply other threads:[~2021-11-30 14:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 9:57 Marco Elver
2021-11-30 12:03 ` Alexander Potapenko
2021-11-30 12:34 ` Vlastimil Babka
2021-11-30 14:33 ` Andrey Konovalov [this message]
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=CA+fCnZdO4OqLqUyCJ6YQbpgAOpDk_BQrUBgP87KQmw7qv7zTZQ@mail.gmail.com \
--to=andreyknvl@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gustavoars@kernel.org \
--cc=imran.f.khan@oracle.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mika.kuoppala@linux.intel.com \
--cc=ryabinin.a.a@gmail.com \
--cc=vbabka@suse.cz \
--cc=vjitta@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox