On 10/06/2015, 06:00 PM, Rasmus Villemoes wrote:
>> --- a/arch/x86/kernel/dumpstack.c
>> +++ b/arch/x86/kernel/dumpstack.c
>> @@ -260,18 +260,18 @@ int __die(const char *str, struct pt_regs *regs, long
>> err)
>> printk(KERN_DEFAULT
>> "%s: %04lx [#%d] ", str, err & 0xffff, ++die_counter);
>> #ifdef CONFIG_PREEMPT
>> - printk("PREEMPT ");
>> + pr_cont("PREEMPT ");
>> #endif
>> #ifdef CONFIG_SMP
>> - printk("SMP ");
>> + pr_cont("SMP ");
>> #endif
>> #ifdef CONFIG_DEBUG_PAGEALLOC
>> - printk("DEBUG_PAGEALLOC ");
>> + pr_cont("DEBUG_PAGEALLOC");
>
> cosmetic: this lost a space.
Oh, good catch. This was left from the times when DEBUG_PAGEALLOC was
last. Now KASAN is, but I added a space to both of them locally for the
time being. Anyway:
> May I suggest
>
> diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
> index 9c30acfadae2..b473a47d1851 100644
> --- a/arch/x86/kernel/dumpstack.c
> +++ b/arch/x86/kernel/dumpstack.c
> @@ -257,21 +257,23 @@ int __die(const char *str, struct pt_regs *regs, long
> err)
> unsigned short ss;
> unsigned long sp;
> #endif
> - printk(KERN_DEFAULT
> - "%s: %04lx [#%d] ", str, err & 0xffff, ++die_counter);
> + static const char build_flags[] = ""
> #ifdef CONFIG_PREEMPT
> - printk("PREEMPT ");
> + " PREEMPT"
> #endif
> #ifdef CONFIG_SMP
> - printk("SMP ");
> + " SMP"
> #endif
> #ifdef CONFIG_DEBUG_PAGEALLOC
> - printk("DEBUG_PAGEALLOC ");
> + " DEBUG_PAGEALLOC"
> #endif
> #ifdef CONFIG_KASAN
> - printk("KASAN");
> + " KASAN"
> #endif
> - printk("\n");
> + ;
> + printk(KERN_DEFAULT
> + "%s: %04lx [#%d]%s\n", str, err & 0xffff, ++die_counter,
> + build_flags);
> if (notify_die(DIE_OOPS, str, regs, err,
> current->thread.trap_nr, SIGSEGV) == NOTIFY_STOP)
> return 1;
>
> instead, so that there's only one printk call and the pr_cont issue goes
> away?
I like this. So if you resend as a proper patch, I will definitely ack
it. But it's up to the maintainers which one they prefer.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
