linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 1/4] Add BUG_XX() debugging options
@ 2016-02-01 23:35 Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 2/4] Add WARN_XX() " Jeffrey Merkey
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-01 23:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: hpa, jeffmerkey, mingo, tglx, x86

This patch series adds config options which can be set during compile to
direct the compiler to output a breakpoint instruction anywhere a BUG()
or WARN() macro has been placed in the kernel to trigger the system to
enter a debugger if a bug is detected by the system.  Use of this
compile time option also allows conditional breakpoints to be set in the
kernel with these currently used macros.

This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger, and other areas of the
kernel.

Signed-off-by: Jeffrey Merkey <jeffmerkey@gmail.com>
---
 arch/x86/include/asm/bug.h | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index ba38ebb..df26c2b 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -11,6 +11,13 @@
 # define __BUG_C0	"2:\t.long 1b - 2b, %c0 - 2b\n"
 #endif
 
+#ifdef CONFIG_DEBUG_BUG
+#define BUG()							\
+do {								\
+	asm volatile("int3");					\
+	unreachable();						\
+} while (0)
+#else
 #define BUG()							\
 do {								\
 	asm volatile("1:\tud2\n"				\
@@ -23,7 +30,14 @@ do {								\
 		     "i" (sizeof(struct bug_entry)));		\
 	unreachable();						\
 } while (0)
-
+#endif
+#else
+#ifdef CONFIG_DEBUG_BUG
+#define BUG()							\
+do {								\
+	asm volatile("int3");					\
+	unreachable();						\
+} while (0)
 #else
 #define BUG()							\
 do {								\
@@ -31,6 +45,7 @@ do {								\
 	unreachable();						\
 } while (0)
 #endif
+#endif
 
 #include <asm-generic/bug.h>
 
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v4 2/4] Add WARN_XX() debugging options
  2016-02-01 23:35 [PATCH v4 1/4] Add BUG_XX() debugging options Jeffrey Merkey
@ 2016-02-01 23:35 ` Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 3/4] Add BUG_XX() and " Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options Jeffrey Merkey
  2 siblings, 0 replies; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-01 23:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: arnd, linux-arch

This patch series adds config options which can be set during compile to
direct the compiler to output a breakpoint instruction anywhere a BUG()
or WARN() macro has been placed in the kernel to trigger the system to
enter a debugger if a bug is detected by the system.  Use of this
compile time option also allows conditional breakpoints to be set in the
kernel with these currently used macros.

This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger, and other areas of the
kernel.

Signed-off-by: Jeffrey Merkey <jeffmerkey@gmail.com>
---
 include/asm-generic/bug.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 630dd23..ed86cd2 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -90,14 +90,26 @@ extern void warn_slowpath_null(const char *file, const int line);
 })
 #endif
 
+#ifdef CONFIG_DEBUG_WARN
 #ifndef WARN
-#define WARN(condition, format...) ({						\
+#define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
 	if (unlikely(__ret_warn_on))					\
 		__WARN_printf(format);					\
+	BUG();								\
 	unlikely(__ret_warn_on);					\
 })
 #endif
+#else
+#ifndef WARN
+#define WARN(condition, format...) ({					\
+	int __ret_warn_on = !!(condition);				\
+	if (unlikely(__ret_warn_on))					\
+		__WARN_printf(format);					\
+	unlikely(__ret_warn_on);					\
+})
+#endif
+#endif
 
 #define WARN_TAINT(condition, taint, format...) ({			\
 	int __ret_warn_on = !!(condition);				\
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v4 3/4] Add BUG_XX() and WARN_XX() debugging options
  2016-02-01 23:35 [PATCH v4 1/4] Add BUG_XX() debugging options Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 2/4] Add WARN_XX() " Jeffrey Merkey
@ 2016-02-01 23:35 ` Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options Jeffrey Merkey
  2 siblings, 0 replies; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-01 23:35 UTC (permalink / raw)
  To: linux-kernel
  Cc: akpm, aryabinin, dan.j.williams, dave, jeffmerkey, mingo,
	nikolay, paulmck, vladimir.murzin

This patch series adds config options which can be set during compile to
direct the compiler to output a breakpoint instruction anywhere a BUG()
or WARN() macro has been placed in the kernel to trigger the system to
enter a debugger if a bug is detected by the system.  Use of this
compile time option also allows conditional breakpoints to be set in the
kernel with these currently used macros.

This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger, and other areas of the
kernel.

Signed-off-by: Jeffrey Merkey <jeffmerkey@gmail.com>
---
 lib/Kconfig.debug | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 041f995..81b58cd 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -326,6 +326,28 @@ config SECTION_MISMATCH_WARN_ONLY
 # is preferred to always offer frame pointers as a config
 # option on the architecture (regardless of KERNEL_DEBUG):
 #
+config DEBUG_BUG
+	bool "Set Breakpoint for Kernel BUG() macros"
+	depends on DEBUG_KERNEL && !S390
+	help
+	  Say Y here to enable the kernel to emit a breakpoint instruction
+	  anywhere a BUG_XX() macro has been placed in the system kernel code
+	  intended to catch bugs.
+
+	  This option is used for triggering the OS to try enter a debugger
+	  if one is presently installed on the system.
+
+config DEBUG_WARN
+	bool "Set Breakpoint for Kernel WARN() macros"
+	depends on DEBUG_KERNEL && !S390 && DEBUG_BUG
+	help
+	  Say Y here to enable the kernel to emit a breakpoint instruction
+	  anywhere a WARN_XX() macro has been placed in the system kernel code
+	  intended to catch bugs.
+
+	  This option is used for triggering the OS to try enter a debugger
+	  if one is presently installed on the system.
+
 config ARCH_WANT_FRAME_POINTERS
 	bool
 	help
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options
  2016-02-01 23:35 [PATCH v4 1/4] Add BUG_XX() debugging options Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 2/4] Add WARN_XX() " Jeffrey Merkey
  2016-02-01 23:35 ` [PATCH v4 3/4] Add BUG_XX() and " Jeffrey Merkey
@ 2016-02-01 23:35 ` Jeffrey Merkey
  2016-02-02  1:58   ` Steven Rostedt
  2 siblings, 1 reply; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-01 23:35 UTC (permalink / raw)
  To: linux-kernel
  Cc: Jason, aconole, akpm, andriy.shevchenko, jeffmerkey,
	linus.walleij, nicolas.iooss_linux, pmladek, rostedt, tj

This patch series adds config options which can be set during compile to
direct the compiler to output a breakpoint instruction anywhere a BUG()
or WARN() macro has been placed in the kernel to trigger the system to
enter a debugger if a bug is detected by the system.  Use of this
compile time option also allows conditional breakpoints to be set in the
kernel with these currently used macros.

This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger, and other areas of the
kernel.

Signed-off-by: Jeffrey Merkey <jeffmerkey@gmail.com>
---
 include/linux/printk.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 51dd6b8..dcfb270 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -252,8 +252,16 @@ extern asmlinkage void dump_stack(void) __cold;
  * and other debug macros are compiled out unless either DEBUG is defined
  * or CONFIG_DYNAMIC_DEBUG is set.
  */
+#ifdef CONFIG_DEBUG_WARN
+#define pr_emerg(fmt, ...) \
+({								\
+	printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__);		\
+	BUG();							\
+})
+#else
 #define pr_emerg(fmt, ...) \
 	printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
 #define pr_alert(fmt, ...) \
 	printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_crit(fmt, ...) \
-- 
1.8.3.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options
  2016-02-01 23:35 ` [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options Jeffrey Merkey
@ 2016-02-02  1:58   ` Steven Rostedt
  2016-02-02  2:01     ` Jeffrey Merkey
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2016-02-02  1:58 UTC (permalink / raw)
  To: Jeffrey Merkey
  Cc: linux-kernel, Jason, aconole, akpm, andriy.shevchenko,
	linus.walleij, nicolas.iooss_linux, pmladek, tj

On Mon,  1 Feb 2016 16:35:52 -0700
Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
> ---
>  include/linux/printk.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index 51dd6b8..dcfb270 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -252,8 +252,16 @@ extern asmlinkage void dump_stack(void) __cold;
>   * and other debug macros are compiled out unless either DEBUG is defined
>   * or CONFIG_DYNAMIC_DEBUG is set.
>   */
> +#ifdef CONFIG_DEBUG_WARN
> +#define pr_emerg(fmt, ...) \
> +({								\
> +	printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__);		\
> +	BUG();							\

This look rather heavy handed for a debug feature. This will crash any
kernel on a pr-emerg(), similar to a panic on warning. Not only that,
for cases that cal pr_emerg() more than once, it crashes on the first
instance.

What about adding a condition that can be set set in /proc/sys/kernel/
A file called something like crash_on_print_emerg ?

	BUG_ON(crash_on_pr_emerg);

-- Steve

> +})
> +#else
>  #define pr_emerg(fmt, ...) \
>  	printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
> +#endif
>  #define pr_alert(fmt, ...) \
>  	printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
>  #define pr_crit(fmt, ...) \

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options
  2016-02-02  1:58   ` Steven Rostedt
@ 2016-02-02  2:01     ` Jeffrey Merkey
  2016-02-02 19:40       ` Maciej W. Rozycki
  0 siblings, 1 reply; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-02  2:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: linux-kernel, Jason, aconole, akpm, andriy.shevchenko,
	linus.walleij, nicolas.iooss_linux, pmladek, tj

On 2/1/16, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon,  1 Feb 2016 16:35:52 -0700
> Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
>> ---
>>  include/linux/printk.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/printk.h b/include/linux/printk.h
>> index 51dd6b8..dcfb270 100644
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -252,8 +252,16 @@ extern asmlinkage void dump_stack(void) __cold;
>>   * and other debug macros are compiled out unless either DEBUG is
>> defined
>>   * or CONFIG_DYNAMIC_DEBUG is set.
>>   */
>> +#ifdef CONFIG_DEBUG_WARN
>> +#define pr_emerg(fmt, ...) \
>> +({								\
>> +	printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__);		\
>> +	BUG();							\
>
> This look rather heavy handed for a debug feature. This will crash any
> kernel on a pr-emerg(), similar to a panic on warning. Not only that,
> for cases that cal pr_emerg() more than once, it crashes on the first
> instance.
>
> What about adding a condition that can be set set in /proc/sys/kernel/
> A file called something like crash_on_print_emerg ?
>
> 	BUG_ON(crash_on_pr_emerg);
>
> -- Steve
>

If a debugger is loaded it will not crash, just enter the debugger.
But yes, it will int3 if set and no debugger has been loaded to handle
the int3 condition.  Hmmm.  Maybe its better just to skip calling
pr_emerg and put this logic as a single call somewhere else.

Jeff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options
  2016-02-02  2:01     ` Jeffrey Merkey
@ 2016-02-02 19:40       ` Maciej W. Rozycki
  2016-02-02 22:18         ` Jeffrey Merkey
  0 siblings, 1 reply; 8+ messages in thread
From: Maciej W. Rozycki @ 2016-02-02 19:40 UTC (permalink / raw)
  To: Jeffrey Merkey
  Cc: Steven Rostedt, linux-kernel, Jason, aconole, Andrew Morton,
	andriy.shevchenko, linus.walleij, nicolas.iooss_linux, pmladek,
	tj

On Mon, 1 Feb 2016, Jeffrey Merkey wrote:

> If a debugger is loaded it will not crash, just enter the debugger.
> But yes, it will int3 if set and no debugger has been loaded to handle
> the int3 condition.  Hmmm.  Maybe its better just to skip calling
> pr_emerg and put this logic as a single call somewhere else.

 What's the point?  If you have a debugger loaded, then surely you can 
just set a breakpoint anywhere you like using whatever user interface the 
debugger provides for setting breakpoints.  You can actually set any 
number of software breakpoints you like wherever you like, depending on 
what you actually want to debug.  I fail to see why it would have to be 
prearranged within the kernel -- do you have a configuration where you run 
the kernel from ROM by any chance?

  Maciej

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options
  2016-02-02 19:40       ` Maciej W. Rozycki
@ 2016-02-02 22:18         ` Jeffrey Merkey
  0 siblings, 0 replies; 8+ messages in thread
From: Jeffrey Merkey @ 2016-02-02 22:18 UTC (permalink / raw)
  To: Maciej W. Rozycki
  Cc: Steven Rostedt, linux-kernel, Jason, aconole, Andrew Morton,
	andriy.shevchenko, linus.walleij, nicolas.iooss_linux, pmladek,
	tj

On 2/2/16, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Mon, 1 Feb 2016, Jeffrey Merkey wrote:
>
>> If a debugger is loaded it will not crash, just enter the debugger.
>> But yes, it will int3 if set and no debugger has been loaded to handle
>> the int3 condition.  Hmmm.  Maybe its better just to skip calling
>> pr_emerg and put this logic as a single call somewhere else.
>
>  What's the point?  If you have a debugger loaded, then surely you can
> just set a breakpoint anywhere you like using whatever user interface the
> debugger provides for setting breakpoints.  You can actually set any
> number of software breakpoints you like wherever you like, depending on
> what you actually want to debug.  I fail to see why it would have to be
> prearranged within the kernel -- do you have a configuration where you run
> the kernel from ROM by any chance?
>
>   Maciej
>

No ROM here.  I resubmitted this as series 5 and dropped the change to
pr_emerg for the very reasons you stated.  I verified what you said
was correct by reviewing several code paths and its not a good place
for that.  Folks expect this function to act like a printk on
steroids, not as a terminal placement of a BUG().

Jeff

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-02-02 22:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-01 23:35 [PATCH v4 1/4] Add BUG_XX() debugging options Jeffrey Merkey
2016-02-01 23:35 ` [PATCH v4 2/4] Add WARN_XX() " Jeffrey Merkey
2016-02-01 23:35 ` [PATCH v4 3/4] Add BUG_XX() and " Jeffrey Merkey
2016-02-01 23:35 ` [PATCH v4 4/4] pr_emerg add WARN_XX() debugger options Jeffrey Merkey
2016-02-02  1:58   ` Steven Rostedt
2016-02-02  2:01     ` Jeffrey Merkey
2016-02-02 19:40       ` Maciej W. Rozycki
2016-02-02 22:18         ` Jeffrey Merkey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).