From: Qian Cai <cai@lca.pw>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: Kmemleak infrastructure improvement for task_struct leaks and call_rcu()
Date: Tue, 12 May 2020 14:09:30 -0400 [thread overview]
Message-ID: <E812E94D-B8B7-4934-965A-3038F56FD980@lca.pw> (raw)
In-Reply-To: <20200512141535.GA14943@gaia>
> On May 12, 2020, at 10:15 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> In this case it uses kref_get() to increment the refcount. We could add
> a kmemleak_add_trace() which allocates a new array and stores the stack
> trace, linked to the original object. Similarly for kref_put().
>
> If we do this for each inc/dec call, I'd leave it off as default and
> only enable it explicitly by cmdline argument or
> /sys/kerne/debug/kmemleak when needed. In most cases you'd hope there is
> no leak, so no point in tracking additional metadata. But if you do hit
> a problem, just enable the additional tracking to help with the
> debugging.
Well, we would like those testing bots to report kmemleak (I knew there would be many false positives) with those additional information of refcount leaks in case they found ones, albeit never saw one from those bots at all yet.
Since some of those bots will run fuzzers, so it would be difficult to reproduce. Thus, the option has to be enabled by default somehow. Otherwise, they could easily miss it in the first place. I’ll look into the see if we could make it fairly low overhead.
next prev parent reply other threads:[~2020-05-12 18:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 16:22 Kmemleak infrastructure improvement for task_struct leaks and call_rcu() Qian Cai
2020-05-06 17:40 ` Paul E. McKenney
2020-05-07 17:14 ` Catalin Marinas
2020-05-07 17:54 ` Paul E. McKenney
2020-05-07 17:16 ` Catalin Marinas
2020-05-07 17:29 ` Qian Cai
2020-05-09 9:44 ` Catalin Marinas
2020-05-10 21:27 ` Qian Cai
2020-05-12 14:15 ` Catalin Marinas
2020-05-12 18:09 ` Qian Cai [this message]
2020-05-13 9:59 ` Catalin Marinas
2020-05-17 22:32 ` Qian Cai
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=E812E94D-B8B7-4934-965A-3038F56FD980@lca.pw \
--to=cai@lca.pw \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).