linux-kernel - Re: [PATCH 03/31] Add debugger entry points for AVR32

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]

Message-ID: <20160128201649.GA11179@samfundet.no>
Date:	Thu, 28 Jan 2016 21:16:49 +0100
From:	Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>
To:	Jeffrey Merkey <jeffmerkey@...il.com>
Cc:	linux-kernel@...r.kernel.org, hskinnemoen@...il.com,
	linux.mdb@...il.com
Subject: Re: [PATCH 03/31] Add debugger entry points for AVR32

Around Thu 28 Jan 2016 12:46:17 -0700 or thereabout, Jeffrey Merkey wrote:
> This patch series adds an export which can be set by system debuggers to
> direct the hard lockup and soft lockup detector to trigger a breakpoint
> exception and enter a debugger if one is active.  It is assumed that if
> someone sets this variable, then an breakpoint handler of some sort will
> be actively loaded or registered via the notify die handler chain.
> 
> This addition is extremely useful for debugging hard and soft lockups
> real time and quickly from a console debugger.
> 
> Signed-off-by: Jeffrey Merkey <jeffmerkey@...il.com>

Acked-by: Hans-Christian Egtvedt <egtvedt@...fundet.no>

> ---
>  arch/avr32/include/asm/kdebug.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/avr32/include/asm/kdebug.h b/arch/avr32/include/asm/kdebug.h
> index f930ce2..f67caf0 100644
> --- a/arch/avr32/include/asm/kdebug.h
> +++ b/arch/avr32/include/asm/kdebug.h
> @@ -1,6 +1,10 @@
>  #ifndef __ASM_AVR32_KDEBUG_H
>  #define __ASM_AVR32_KDEBUG_H
>  
> +static inline void arch_breakpoint(void)
> +{
> +}

Will not this just be optimized away? Are you expecting other developers to
add a no-op assembler instruction into this function body?

<snipp>
-- 
Best regards, Hans-Christian Egtvedt