From: Marco Elver <elver@google.com>
To: chenqiwu <qiwuchen55@gmail.com>
Cc: 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: Mon, 5 Aug 2024 08:50:57 +0200 [thread overview]
Message-ID: <CANpmjNPEo=9x1FewrZYNG+YEK_XiX5gx8XNKjD9+bw7XWBV9Xw@mail.gmail.com> (raw)
In-Reply-To: <20240805033534.GA15091@rlk>
On Mon, 5 Aug 2024 at 05:35, chenqiwu <qiwuchen55@gmail.com> wrote:
>
> On Sun, Aug 04, 2024 at 10:37:43AM +0200, Marco Elver wrote:
> >
> > Well, what I'm saying, having this info also for FREED objects on the
> > free stack can be useful in some debugging scenarios when you get a
> > use-after-free, and you want to know the elapsed time since the free
> > happened. I have done this calculation manually before, which is why I
> > suggested it. Maybe it's not useful for you for finding leaks, but
> > that's just one usecase.
> >
> Agreed with your concern scenarios.
> How about the following change with additonal object state info?
>
> + u64 interval_nsec = local_clock() - meta->alloc_track.ts_nsec;
> + unsigned long rem_interval_nsec = do_div(interval_nsec, NSEC_PER_SEC);
>
> /* Timestamp matches printk timestamp format. */
> - seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus:\n",
> + seq_con_printf(seq, "%s by task %d on cpu %d at %lu.%06lus (%lu.%06lus ago) for %s object:\n",
> 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,
> + meta->state == KFENCE_OBJECT_ALLOCATED? "allocated" : "freed");
>
> In this way, we can find leaks by grep "allocated object" and inspect the elapsed time of
> use-after-free by grep "freed object".
The "allocated/freed" info is superfluous, as freed objects will have
a free stack.
Consider a slightly better script vs. just using grep.
/sys/kernel/debug/kfence/objects is of secondary concern and was added
primarily as a debugging aid for KFENCE developers. We never thought
it could be used to look for leaks, but good you found another use for
it. ;-)
The priority is to keep regular error reports generated by KFENCE
readable. Adding this "allocated/freed" info just makes the line
longer and is not useful.
I'm happy with the "(%lu.%06lus ago)" part alone.
next prev parent reply other threads:[~2024-08-05 6:51 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
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 [this message]
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='CANpmjNPEo=9x1FewrZYNG+YEK_XiX5gx8XNKjD9+bw7XWBV9Xw@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=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