All of lore.kernel.org
 help / color / mirror / Atom feed
From: chenqiwu <qiwuchen55@gmail.com>
To: Marco Elver <elver@google.com>
Cc: Qiwu Chen <qiwuchen55@gmail.com>,
	glider@google.com, dvyukov@google.com, akpm@linux-foundation.org,
	kasan-dev@googlegroups.com, linux-mm@kvack.org
Subject: Re: [PATCH] mm: kfence: print the age time for alloacted objectes to trace memleak
Date: Sun, 4 Aug 2024 11:46:07 +0800	[thread overview]
Message-ID: <20240804034607.GA11291@rlk> (raw)
In-Reply-To: <CANpmjNNf8n=x+TnsSQ=kDMpDmmFevYdLrB2R0WMtZiirAUX=JA@mail.gmail.com>

On Sat, Aug 03, 2024 at 04:51:45PM +0200, Marco Elver wrote:
> 
> typo: convenience
> 
> What do you mean by "object leak"?
> 
It means an allocated object of slab memory which is considered orphan,
perhaps it's more clear to say "For a convenience of tracing memory leaks by kfence",
what do you think?
> 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.
>
The extra elapsed time of current allocated object would be useful to figure out memory
leaks when inspect /sys/kernel/debug/kfence/objects.
> 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?
> 
The kmemleak tool has limitations and drawbacks which cannot be used in productive environment
directly. KFENCE is a good choice to find leaks in productive environment.
> > alloacted objectes in kfence_print_stack().
> 
> typo: allocated objects
> 
Thank's for your comment.
> 
> 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?
> 
It does not work for me actually, since it's unintuitive to figure out memory leaks
by the elapsed time of allocated stacks when inspect /sys/kernel/debug/kfence/objects.
It's unnecessary to print the elapsed time of allocated stacks for the objects in KFENCE_OBJECT_FREED
state. For the elapsed time of free stacks, it seems no available scenarion currently.
BTW, The change from "age" to "ago" is okay to me!
> >                        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.
> 
I'm not opposed to convert a single statement, but it will have an effort to find leaks.
This change will be helpful to find leaks easier by grep "ago" keyword when inspect /sys/kernel/debug/kfence/objects.

Thanks
Qiwu


  reply	other threads:[~2024-08-04  3:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-03 13:36 [PATCH] mm: kfence: print the age time for alloacted objectes to trace memleak Qiwu Chen
2024-08-03 14:51 ` Marco Elver
2024-08-04  3:46   ` chenqiwu [this message]
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=20240804034607.GA11291@rlk \
    --to=qiwuchen55@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.