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;
MIME-Version: 1.0
References: <20201027175810.GA26121@paulmck-ThinkPad-P72>
In-Reply-To: <20201027175810.GA26121@paulmck-ThinkPad-P72>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Tue, 27 Oct 2020 19:40:19 +0100
Message-ID: <CACT4Y+bB4sZjLx6tL6F5XzxGk5iG7j=SPbDkX_bwRXmXB=JxXA@mail.gmail.com>
Subject: Re: Recording allocation location for blocks of memory?
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Marco Elver <elver@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Andrii Nakryiko <andriin@fb.com>,
        kasan-dev <kasan-dev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Oct 27, 2020 at 6:58 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Hello!
>
> I have vague memories of some facility some time some where that recorded
> who allocated a given block of memory, but am not seeing anything that
> does this at present.  The problem is rare enough and the situation
> sufficiently performance-sensitive that things like ftrace need not apply,
> and the BPF guys suggest that BPF might not be the best tool for this job.
>
> The problem I am trying to solve is that a generic function that detects
> reference count underflow that was passed to call_rcu(), and there are
> a lot of places where the underlying problem might lie, and pretty much
> no information.  One thing that could help is something that identifies
> which use case the underflow corresponds to.
>
> So, is there something out there (including old patches) that, given a
> pointer to allocated memory, gives some information about who allocated
> it?  Or should I risk further inflaming the MM guys by creating one?  ;-)

Hi Paul,

KASAN can do this. However (1) it has non-trivial overhead on its own
(but why would you want to debug something without KASAN anyway :))
(2) there is no support for doing just stack collection without the
rest of KASAN (they are integrated at the moment) (3) there is no
public interface function that does what you want, though, it should
be easy to add it. The code is around here:
https://github.com/torvalds/linux/blob/master/mm/kasan/report.c#L111-L128

Since KASAN already bears all overheads of stack collection/storing I
was thinking that lots of other debugging tools could indeed piggy
back on that and print much more informative errors message when
enabled with KASAN.

Since recently KASAN also memorizes up to 2 "other" stacks per
objects. This is currently used to memorize call_rcu stacks, since
they are frequently more useful than actual free stacks for
rcu-managed objects.
That mechanism could also memorize last refcount stacks, however I
afraid that they will evict everything else, since we have only 2
slots, and frequently there are lots of refcount operations.