linux-kernel - Re: [PATCH] RFC: debugobjects: capture stack traces at

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Mar 2018 20:44:33 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
cc:     Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Waiman Long <longman@...hat.com>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH] RFC: debugobjects: capture stack traces at _init()
 time

On Tue, 20 Mar 2018, Daniel Vetter wrote:

> Sometimes it's really easy to know which object has gone boom and
> where the offending code is, and sometimes it's really hard. One case
> we're trying to hunt down is when module unload catches a live debug
> object, with a module with lots of them.
> 
> Capture a full stack trace from debug_object_init() and dump it when
> there's a problem.
> 
> FIXME: Should we have a separate Kconfig knob for the backtraces,
> they're quite expensive? Atm I'm just selecting it for the general
> debug object stuff.

Just make it boot time enabled. We really want to be able to switch it off.

> +#define ODEBUG_STACKDEPTH 32

Do we really need it that deep? I doubt that.

> +static noinline depot_stack_handle_t save_stack(struct debug_obj *obj)
> +{
> +	unsigned long entries[ODEBUG_STACKDEPTH];
> +	struct stack_trace trace = {
> +		.entries = entries,
> +		.max_entries = ODEBUG_STACKDEPTH,
> +		.skip = 2
> +	};
> +
> +	save_stack_trace(&trace);
> +	if (trace.nr_entries != 0 &&
> +	    trace.entries[trace.nr_entries-1] == ULONG_MAX)
> +		trace.nr_entries--;
> +
> +	/* May be called under spinlock, so avoid sleeping */
> +	return depot_save_stack(&trace, GFP_NOWAIT);

I really don't like the idea of unconditional allocations in that code
path. We went great length to make it perform halfways sane with the
pool. Though we should actually have per cpu pools to avoid the lock
contention, but thats a different problem.

I'd rather make the storage a fixed size allocation which is appended
to the debug object. Something like this:

struct debug_obj_trace {
	struct stack_trace	trace;
	unsigned long		entries[ODEBUG_STACKDEPTH];
};	

struct debug_obj {
	unsigned int		astate;
	void			*object;
	struct debug_obj_descr	*descr;
	struct debug_obj_trace	trace[0];
};

void __init debug_objects_mem_init(void)
{
	unsigned long objsize = sizeof (struct debug_obj);

 	if (!debug_objects_enabled)
 		return;
 
	if (debug_objects_trace_stack)
		objsize += sizeof(struct debug_obj_trace);

	obj_cache = kmem_cache_create("debug_objects_cache", objsize, 0,
 				      SLAB_DEBUG_OBJECTS, NULL);

__debug_object_init(void *addr, struct debug_obj_descr *descr, int onstack)
{
	....
 	case ODEBUG_STATE_NONE:
 	case ODEBUG_STATE_INIT:
 	case ODEBUG_STATE_INACTIVE:
		if (debug_object_trace_stack) {
			obj->trace[0].trace.entries = obj->trace[0].entries;
			save_stack_trace(&trace[0].trace);
		}
 
That means we need to size the static objects which are used during early
boot with stack under the assumption that stack tracing is enabled, but
that's simple enough.

Hmm?

Thanks,

	tglx