linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Qiwu Chen <qiwuchen55@gmail.com>
Cc: glider@google.com, dvyukov@google.com, akpm@linux-foundation.org,
	 kasan-dev@googlegroups.com, linux-mm@kvack.org,
	 "qiwu.chen" <qiwu.chen@transsion.com>
Subject: Re: [PATCH] mm: kfence: print the age time for alloacted objectes to trace memleak
Date: Sat, 3 Aug 2024 16:51:45 +0200	[thread overview]
Message-ID: <CANpmjNNf8n=x+TnsSQ=kDMpDmmFevYdLrB2R0WMtZiirAUX=JA@mail.gmail.com> (raw)
In-Reply-To: <20240803133608.2124-1-chenqiwu@xiaomi.com>

On Sat, 3 Aug 2024 at 15:36, Qiwu Chen <qiwuchen55@gmail.com> wrote:
>
> From: "qiwu.chen" <qiwu.chen@transsion.com>
>
> For a convienince of tracing slab object leak, print the age time for

typo: convenience

What do you mean by "object leak"?

From what I see the additional info is only printed on out-of-bounds access.

Or do you mean when you inspect /sys/kernel/debug/kfence/objects? If
so, that information would be useful in the commit message.

However, to detect leaks there are better tools than KFENCE. Have you
tried KMEMLEAK? KFENCE is really not a good choice to manually look
for old objects, which themselves are sampled, to find leaks.
Have you been able to successfully debug a leak this way?

> alloacted objectes in kfence_print_stack().

typo: allocated objects

> Signed-off-by: qiwu.chen <qiwu.chen@transsion.com>
> ---
>  mm/kfence/report.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kfence/report.c b/mm/kfence/report.c
> index c509aed326ce..44c3f82b25a8 100644
> --- a/mm/kfence/report.c
> +++ b/mm/kfence/report.c
> @@ -16,6 +16,7 @@
>  #include <linux/sprintf.h>
>  #include <linux/stacktrace.h>
>  #include <linux/string.h>
> +#include <linux/sched/clock.h>
>  #include <trace/events/error_report.h>
>
>  #include <asm/kfence.h>
> @@ -110,9 +111,18 @@ static void kfence_print_stack(struct seq_file *seq, const struct kfence_metadat
>         unsigned long rem_nsec = do_div(ts_sec, NSEC_PER_SEC);
>
>         /* Timestamp matches printk timestamp format. */
> -       seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n",
> +       if (meta->state == KFENCE_OBJECT_ALLOCATED) {

In principle, the additonal info is convenient, but I'd like to
generalize if possible.

> +               u64 interval_nsec = local_clock() - meta->alloc_track.ts_nsec;
> +               unsigned long rem_interval_nsec = do_div(interval_nsec, NSEC_PER_SEC);
> +
> +               seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus (age: %lu.%06lus):\n",

I've found myself trying to figure out the elapsed time since the
allocation or free, based on the current timestamp.

So something that would be more helpful is if you just change the
printed line for all alloc and free stack infos to say something like:

    seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus
(%lu.%06lus ago):\n",

So rather than saying this info is the "age", we just say the elapsed
time. That generalizes this bit of info, and it'll be available for
both alloc and free stacks.

Does that work for you?

>                        show_alloc ? "allocated" : "freed", track->pid,
> -                      track->cpu, (unsigned long)ts_sec, rem_nsec / 1000);
> +                      track->cpu, (unsigned long)ts_sec, rem_nsec / 1000,
> +                          (unsigned long)interval_nsec, rem_interval_nsec / 1000);
> +       } else

Add braces {} even though it's a single statement - it spans several
lines and the above is also {}-enclosed, so it looks balanced.

But if you follow my suggestion, you won't have the else branch anymore.

> +               seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n",
> +                                  show_alloc ? "allocated" : "freed", track->pid,
> +                                  track->cpu, (unsigned long)ts_sec, rem_nsec / 1000);
>
>         if (track->num_stack_entries) {
>                 /* Skip allocation/free internals stack. */


  reply	other threads:[~2024-08-03 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-03 13:36 Qiwu Chen
2024-08-03 14:51 ` Marco Elver [this message]
2024-08-04  3:46   ` chenqiwu
2024-08-04  8:37     ` Marco Elver
2024-08-05  3:35       ` chenqiwu
2024-08-05  6:50         ` Marco Elver
2024-08-05 14:06           ` chenqiwu
2024-08-05 14:18             ` Marco Elver

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='CANpmjNNf8n=x+TnsSQ=kDMpDmmFevYdLrB2R0WMtZiirAUX=JA@mail.gmail.com' \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-mm@kvack.org \
    --cc=qiwu.chen@transsion.com \
    --cc=qiwuchen55@gmail.com \
    /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