From: Thomas Gleixner <tglx@linutronix.de>
To: greearb@candelatech.com, linux-kernel@vger.kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Subject: Re: [PATCH/RFC] debugobjects/slub: Print slab info and backtrace.
Date: Sun, 05 Nov 2023 10:35:15 +0100 [thread overview]
Message-ID: <878r7cilv0.ffs@tglx> (raw)
In-Reply-To: <20231103013704.1232723-1-greearb@candelatech.com>
On Thu, Nov 02 2023 at 18:37, greearb@candelatech.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
next prev parent reply other threads:[~2023-11-05 9:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 1:37 [PATCH/RFC] debugobjects/slub: Print slab info and backtrace greearb
2023-11-03 1:49 ` Ben Greear
2023-11-05 16:20 ` Thomas Gleixner
2023-11-05 17:40 ` Ben Greear
2023-11-06 0:13 ` Thomas Gleixner
2023-11-05 9:35 ` Thomas Gleixner [this message]
2023-11-09 5:19 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878r7cilv0.ffs@tglx \
--to=tglx@linutronix.de \
--cc=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox