Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: Kmemleak infrastructure improvement for task_struct leaks and call_rcu()
Date:   Tue, 12 May 2020 14:09:30 -0400
Message-Id: <E812E94D-B8B7-4934-965A-3038F56FD980@lca.pw>
References: <20200512141535.GA14943@gaia>
Cc:     Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>,
        "Paul E. McKenney" <paulmck@kernel.org>
In-Reply-To: <20200512141535.GA14943@gaia>
To:     Catalin Marinas <catalin.marinas@arm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 12, 2020, at 10:15 AM, Catalin Marinas <catalin.marinas@arm.com> wr=
ote:
>=20
> 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().
>=20
> 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 woul=
d be many false positives) with those additional information of refcount lea=
ks 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 repro=
duce. Thus, the option has to be enabled by default somehow. Otherwise, they=
 could easily miss it in the first place. I=E2=80=99ll look into the see if w=
e could make it fairly low overhead.=