linux-kernel - Re: [PATCH RT] arm/unwind: fail on unwind in irq disabled regions

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:	Thu, 13 Feb 2014 23:57:45 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
cc:	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: [PATCH RT] arm/unwind: fail on unwind in irq disabled regions



On Fri, 24 Jan 2014, Sebastian Andrzej Siewior wrote:

> Mostly unwind is done with irqs enabled however SLUB may call it with
> irqs disabled while creating a new SLUB cache.
> 
> I had system freeze while loading a module which called
> kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled
> interrupts and then
> 
> ->new_slab_objects()
>  ->new_slab()
>   ->setup_object()
>    ->setup_object_debug()
>     ->init_tracking()
>      ->set_track()
>       ->save_stack_trace()
>        ->save_stack_trace_tsk()
>         ->walk_stackframe()
>          ->unwind_frame()
>           ->unwind_find_idx()
>            =>spin_lock_irqsave(&unwind_lock);
> 
> I would prefer not to turn this into a raw lock so for now it will just
> fail if it is called with irqs disabled which might return a few "empty"
> traces…

If we really end up with unwinding then the few cycles to follow the
stack are not that important anymore. We really want that output.

Thanks,

	tglx