[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878r7cilv0.ffs@tglx>
Date: Sun, 05 Nov 2023 10:35:15 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: greearb@...delatech.com, linux-kernel@...r.kernel.org
Cc: Ben Greear <greearb@...delatech.com>
Subject: Re: [PATCH/RFC] debugobjects/slub: Print slab info and backtrace.
On Thu, Nov 02 2023 at 18:37, greearb@...delatech.com wrote:
> When debugobjects detects a problem, it may be in generic code
> where the backtraces currently printed are not helpful.
>
> To try to improve this, store the backtrace of where the
> debug_obj was created and print that out when problems
> are found.
To make debugobjects massively slower than it is already.
> Also print out slub info for the object held by the
> debug_obj. In my particular case, this was not super
> useful, appearantly because of all of the KASAN and other
> debugging I have enabled. Still, might provide a few
> clues.
So either it is useful or not. You could have disabled the other
debugging to figure this out, no?
Aside of that this is a separate issue and wants to be split out into a
separate patch if at all.
> diff --git a/include/linux/debugobjects.h b/include/linux/debugobjects.h
> index 32444686b6ff..8e8df719bd88 100644
> --- a/include/linux/debugobjects.h
> +++ b/include/linux/debugobjects.h
> @@ -31,6 +31,11 @@ struct debug_obj {
> unsigned int astate;
> void *object;
> const struct debug_obj_descr *descr;
> +#ifdef CONFIG_STACKDEPOT
If at all then this wants to be CONFIG_DEBUG_OBJECTS_STACKTRACE or such.
> +#define DEBUG_OBJ_ADDRS_COUNT 16
Don't glue a define into the struct. That's unreadable.
> + /* Including stackdepot.h blows up the build, so open-code the handle. */
Seriously no. The obvious fix is to move 'struct debug_obj' into the C
file as it is not used anywhere else.
> + u64 trace_handle;
> +#endif
> };
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index a517256a270b..1f458e473bc5 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -17,6 +17,8 @@
> #include <linux/hash.h>
> #include <linux/kmemleak.h>
> #include <linux/cpu.h>
> +#include <linux/slab.h>
> +#include <linux/stackdepot.h>
>
> #define ODEBUG_HASH_BITS 14
> #define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
> @@ -216,6 +218,33 @@ static struct debug_obj *__alloc_object(struct hlist_head *list)
> return obj;
> }
>
> +#ifdef CONFIG_STACKDEPOT
> +static void debug_print_stack_info(struct debug_obj *object)
> +{
> + if (object->trace_handle) {
> + pr_err("debugobjects: debug_obj allocated at:\n");
> + stack_depot_print(object->trace_handle);
> + pr_err("end of stack dump\n");
> + }
> +}
> +
> +static noinline depot_stack_handle_t set_track_prepare(void)
> +{
> + depot_stack_handle_t trace_handle;
> + unsigned long entries[DEBUG_OBJ_ADDRS_COUNT];
> + unsigned int nr_entries;
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#variable-declarations
> +
> + nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 3);
> + trace_handle = stack_depot_save(entries, nr_entries, GFP_NOWAIT);
> +
> + return trace_handle;
> +}
> +
> +#else
> +static void debug_print_stack_info(struct debug_obj *object) { }
> +static depot_stack_handle_t set_track_prepare(void) { }
> +#endif
> +
> static struct debug_obj *
> alloc_object(void *addr, struct debug_bucket *b, const struct debug_obj_descr *descr)
> {
> @@ -272,6 +301,12 @@ alloc_object(void *addr, struct debug_bucket *b, const struct debug_obj_descr *d
> obj->state = ODEBUG_STATE_NONE;
> obj->astate = 0;
> hlist_add_head(&obj->node, &b->list);
> +
> + /* Save stack of where object was created */
> +#ifdef CONFIG_STACKDEPOT
> + /* kernel backtrace */
> + obj->trace_handle = set_track_prepare();
Handing the object pointer to the function spares the ugly ifdef.
Also what on earth means set_track_prepare()? If I hadn't seen the
function before then I'd had a hard time to decode this. Self
explanatory function names spare also commenting the obvious. I.e. this
whole thing boils down to:
debug_save_stack_trace(obj);
or such.
Thanks,
tglx
Powered by blists - more mailing lists