[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E812E94D-B8B7-4934-965A-3038F56FD980@lca.pw>
Date: Tue, 12 May 2020 14:09:30 -0400
From: Qian Cai <cai@....pw>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Linux-MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Kmemleak infrastructure improvement for task_struct leaks and call_rcu()
> On May 12, 2020, at 10:15 AM, Catalin Marinas <catalin.marinas@....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.
Powered by blists - more mailing lists