2020-09-24 04:14:22

by Walter Wu

[permalink] [raw]
Subject: [PATCH v4 3/6] kasan: print timer and workqueue stack

The aux_stack[2] is reused to record the call_rcu() call stack,
timer init call stack, and enqueuing work call stacks. So that
we need to change the auxiliary stack title for common title,
print them in KASAN report.

Signed-off-by: Walter Wu <[email protected]>
Suggested-by: Marco Elver <[email protected]>
Acked-by: Marco Elver <[email protected]>
Reviewed-by: Dmitry Vyukov <[email protected]>
Reviewed-by: Andrey Konovalov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
---

v2:
- Thanks for Marco suggestion.
- We modify aux stack title name in KASAN report
in order to print call_rcu()/timer/workqueue stack.

---
mm/kasan/report.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 4f49fa6cd1aa..886809d0a8dd 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,

#ifdef CONFIG_KASAN_GENERIC
if (alloc_info->aux_stack[0]) {
- pr_err("Last call_rcu():\n");
+ pr_err("Last potentially related work creation:\n");
print_stack(alloc_info->aux_stack[0]);
pr_err("\n");
}
if (alloc_info->aux_stack[1]) {
- pr_err("Second to last call_rcu():\n");
+ pr_err("Second to last potentially related work creation:\n");
print_stack(alloc_info->aux_stack[1]);
pr_err("\n");
}
--
2.18.0


2020-09-24 11:49:27

by Alexander Potapenko

[permalink] [raw]
Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

On Thu, Sep 24, 2020 at 6:05 AM Walter Wu <[email protected]> wrote:
>
> The aux_stack[2] is reused to record the call_rcu() call stack,
> timer init call stack, and enqueuing work call stacks. So that
> we need to change the auxiliary stack title for common title,
> print them in KASAN report.
>
> Signed-off-by: Walter Wu <[email protected]>
> Suggested-by: Marco Elver <[email protected]>
> Acked-by: Marco Elver <[email protected]>
> Reviewed-by: Dmitry Vyukov <[email protected]>
> Reviewed-by: Andrey Konovalov <[email protected]>
> Cc: Andrey Ryabinin <[email protected]>
> Cc: Alexander Potapenko <[email protected]>
> ---
>
> v2:
> - Thanks for Marco suggestion.
> - We modify aux stack title name in KASAN report
> in order to print call_rcu()/timer/workqueue stack.
>
> ---
> mm/kasan/report.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 4f49fa6cd1aa..886809d0a8dd 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,
>
> #ifdef CONFIG_KASAN_GENERIC
> if (alloc_info->aux_stack[0]) {
> - pr_err("Last call_rcu():\n");
> + pr_err("Last potentially related work creation:\n");

This doesn't have to be a work creation (expect more callers of
kasan_record_aux_stack() in the future), so maybe change the wording
here to "Last potentially related auxiliary stack"?

2020-09-24 11:56:31

by Marco Elver

[permalink] [raw]
Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko <[email protected]> wrote:
>
> On Thu, Sep 24, 2020 at 6:05 AM Walter Wu <[email protected]> wrote:
> >
> > The aux_stack[2] is reused to record the call_rcu() call stack,
> > timer init call stack, and enqueuing work call stacks. So that
> > we need to change the auxiliary stack title for common title,
> > print them in KASAN report.
> >
> > Signed-off-by: Walter Wu <[email protected]>
> > Suggested-by: Marco Elver <[email protected]>
> > Acked-by: Marco Elver <[email protected]>
> > Reviewed-by: Dmitry Vyukov <[email protected]>
> > Reviewed-by: Andrey Konovalov <[email protected]>
> > Cc: Andrey Ryabinin <[email protected]>
> > Cc: Alexander Potapenko <[email protected]>
> > ---
> >
> > v2:
> > - Thanks for Marco suggestion.
> > - We modify aux stack title name in KASAN report
> > in order to print call_rcu()/timer/workqueue stack.
> >
> > ---
> > mm/kasan/report.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 4f49fa6cd1aa..886809d0a8dd 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,
> >
> > #ifdef CONFIG_KASAN_GENERIC
> > if (alloc_info->aux_stack[0]) {
> > - pr_err("Last call_rcu():\n");
> > + pr_err("Last potentially related work creation:\n");
>
> This doesn't have to be a work creation (expect more callers of
> kasan_record_aux_stack() in the future), so maybe change the wording
> here to "Last potentially related auxiliary stack"?

I suggested "work creation" as it's the most precise for what it is
used for now.

What other users do you have in mind in future that are not work creation?

2020-09-24 12:15:28

by Alexander Potapenko

[permalink] [raw]
Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

On Thu, Sep 24, 2020 at 1:55 PM Marco Elver <[email protected]> wrote:
>
> On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko <[email protected]> wrote:
> >
> > On Thu, Sep 24, 2020 at 6:05 AM Walter Wu <[email protected]> wrote:
> > >
> > > The aux_stack[2] is reused to record the call_rcu() call stack,
> > > timer init call stack, and enqueuing work call stacks. So that
> > > we need to change the auxiliary stack title for common title,
> > > print them in KASAN report.
> > >
> > > Signed-off-by: Walter Wu <[email protected]>
> > > Suggested-by: Marco Elver <[email protected]>
> > > Acked-by: Marco Elver <[email protected]>
> > > Reviewed-by: Dmitry Vyukov <[email protected]>
> > > Reviewed-by: Andrey Konovalov <[email protected]>
> > > Cc: Andrey Ryabinin <[email protected]>
> > > Cc: Alexander Potapenko <[email protected]>
> > > ---
> > >
> > > v2:
> > > - Thanks for Marco suggestion.
> > > - We modify aux stack title name in KASAN report
> > > in order to print call_rcu()/timer/workqueue stack.
> > >
> > > ---
> > > mm/kasan/report.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > index 4f49fa6cd1aa..886809d0a8dd 100644
> > > --- a/mm/kasan/report.c
> > > +++ b/mm/kasan/report.c
> > > @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,
> > >
> > > #ifdef CONFIG_KASAN_GENERIC
> > > if (alloc_info->aux_stack[0]) {
> > > - pr_err("Last call_rcu():\n");
> > > + pr_err("Last potentially related work creation:\n");
> >
> > This doesn't have to be a work creation (expect more callers of
> > kasan_record_aux_stack() in the future), so maybe change the wording
> > here to "Last potentially related auxiliary stack"?
>
> I suggested "work creation" as it's the most precise for what it is
> used for now.

I see, then maybe my suggestion is premature.

> What other users do you have in mind in future that are not work creation?

I think saving stacks may help in any case where an object is reused
for a different purpose without reallocation.
SKBs, maybe?


--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

2020-09-24 12:25:56

by Marco Elver

[permalink] [raw]
Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack

On Thu, 24 Sep 2020 at 14:11, Alexander Potapenko <[email protected]> wrote:
>
> On Thu, Sep 24, 2020 at 1:55 PM Marco Elver <[email protected]> wrote:
> >
> > On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko <[email protected]> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 6:05 AM Walter Wu <[email protected]> wrote:
> > > >
> > > > The aux_stack[2] is reused to record the call_rcu() call stack,
> > > > timer init call stack, and enqueuing work call stacks. So that
> > > > we need to change the auxiliary stack title for common title,
> > > > print them in KASAN report.
> > > >
> > > > Signed-off-by: Walter Wu <[email protected]>
> > > > Suggested-by: Marco Elver <[email protected]>
> > > > Acked-by: Marco Elver <[email protected]>
> > > > Reviewed-by: Dmitry Vyukov <[email protected]>
> > > > Reviewed-by: Andrey Konovalov <[email protected]>
> > > > Cc: Andrey Ryabinin <[email protected]>
> > > > Cc: Alexander Potapenko <[email protected]>
> > > > ---
> > > >
> > > > v2:
> > > > - Thanks for Marco suggestion.
> > > > - We modify aux stack title name in KASAN report
> > > > in order to print call_rcu()/timer/workqueue stack.
> > > >
> > > > ---
> > > > mm/kasan/report.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > > index 4f49fa6cd1aa..886809d0a8dd 100644
> > > > --- a/mm/kasan/report.c
> > > > +++ b/mm/kasan/report.c
> > > > @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object,
> > > >
> > > > #ifdef CONFIG_KASAN_GENERIC
> > > > if (alloc_info->aux_stack[0]) {
> > > > - pr_err("Last call_rcu():\n");
> > > > + pr_err("Last potentially related work creation:\n");
> > >
> > > This doesn't have to be a work creation (expect more callers of
> > > kasan_record_aux_stack() in the future), so maybe change the wording
> > > here to "Last potentially related auxiliary stack"?
> >
> > I suggested "work creation" as it's the most precise for what it is
> > used for now.
>
> I see, then maybe my suggestion is premature.
>
> > What other users do you have in mind in future that are not work creation?
>
> I think saving stacks may help in any case where an object is reused
> for a different purpose without reallocation.
> SKBs, maybe?

I currently don't know, it's hard to say without having a report that
we can't debug without it.

The litmus test for if it's useful would probably be "do we need this
stacktrace to debug a use-after-free/double-free?". If the answer is
maybe (and not yes!), I'd err on the side of not going overboard with
these, because we only have limited storage anyway. "Work creation" is
a clear case of "we loose information to the original caller" and need
it to debug. But of course, if there are similar issues elsewhere, we
need to identify them and then decide if we need it.