Messages in this thread | | | Date | Tue, 27 Oct 2020 12:58:19 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Recording allocation location for blocks of memory? |
| |
On Tue, Oct 27, 2020 at 07:40:19PM +0100, Dmitry Vyukov wrote: > 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.
I am guessing that KASAN's overhead make it a no-go in this case (in production), but am checking. But this might change if we can reproduce in a more controlled setting.
Huh. I bet that I could do something with the information accessed by print_tracking() in the slub allocator. This of course means that I am betting that we could run with CONFIG_SLUB_DEBUG=y. Thoughts?
Thanx, Paul
| |