[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+fCnZenG-jQqXigPDOrxrnfzXnuirLOigvCWOCoXu=5Wp12EA@mail.gmail.com>
Date: Fri, 25 Oct 2024 18:59:26 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Nihar Chaithanya <niharchaithanya@...il.com>
Cc: elver@...gle.com, ryabinin.a.a@...il.com, glider@...gle.com,
dvyukov@...gle.com, skhan@...uxfoundation.org, kasan-dev@...glegroups.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] kasan:report: filter out kasan related stack entries
On Fri, Oct 25, 2024 at 4:48 AM Nihar Chaithanya
<niharchaithanya@...il.com> wrote:
>
> When I included ip-based skipping for filtering access stack trace the
> output was
> inconsistent where the Freed track was not fully printed and it also
> triggered
> the following warning a few times:
>
> [ 6.467470][ T4653] Freed by task 511183648:
> [ 6.467792][ T4653] ------------[ cut here ]------------
> [ 6.468194][ T4653] pool index 100479 out of bounds (466) for stack
> id ffff8880
> [ 6.468862][ T4653] WARNING: CPU: 1 PID: 4653 at lib/stackdepot.c:452
> depot_fetch_stack+0x86/0xb0
>
> This was not present when using pattern based skipping. Does modifying
> access
> stack trace when using sanitize_stack_entries() modify the free and
> alloc tracks
> as well? In that case shall we just use pattern based skipping.
To clarify once again: we only want the ip-based filtering for the
access stack trace (the one printed directly from print_report()). For
Allocated/Freed stack traces, we want to use the pattern-based
filtering.
Powered by blists - more mailing lists