[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <836351a4-581d-325f-862f-99c0c4f98e19@arista.com>
Date: Wed, 6 Nov 2019 16:06:44 +0000
From: Dmitry Safonov <dima@...sta.com>
To: Petr Mladek <pmladek@...e.com>, Max Filippov <jcmvbkbc@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>, Jiri Slaby <jslaby@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Chris Zankel <chris@...kel.net>,
"open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@...ux-xtensa.org>
Subject: Re: [PATCH 43/50] xtensa: Add show_stack_loglvl()
On 11/6/19 8:15 AM, Petr Mladek wrote:
> On Tue 2019-11-05 20:13:22, Max Filippov wrote:
[..]
>>> @@ -511,16 +512,21 @@ void show_stack(struct task_struct *task, unsigned long *sp)
>>> sp = stack_pointer(task);
>>> stack = sp;
>>>
>>> - pr_info("Stack:\n");
>>> + printk("%sStack:\n", loglvl);
>>>
>>> for (i = 0; i < kstack_depth_to_print; i++) {
>>> if (kstack_end(sp))
>>> break;
>>> - pr_cont(" %08lx", *sp++);
>>> + printk("%s %08lx", loglvl, *sp++);
>
> KERN_CONT can be combined with any other loglevel.
> So you could keep using pr_cont() together with explicit loglevel:
>
> pr_cont("%s %08lx", loglvl, *sp++);
Yes, that's what I had, but than misread the printk() code and thought
that it doesn't add '\n' to messages.. Will fix.
> It should fix the problems reported below.
>
> Well, the preferred solution would be to snprintf() the continuous
> line into a temporary buffer. And printk() it when it is complete.
> pr_cont() is not reliable when more CPUs print at the same time.
Yep. Not sure if doing it now in those per-arch patches or keep the
changes to minimum.
>
>> This change doesn't work well with printk timestamps, it changes
>> the following output on xtensa architecture
>>
>> [ 3.404675] Stack:
>> [ 3.404861] a05773e2 00000018 bb03dc34 bb03dc30 a0008640 bb03dc70
>> ba9ba410 37c3f000
>> [ 3.405414] 37c3f000 d7c3f000 00000800 bb03dc50 a02b97ed bb03dc90
>> ba9ba400 ba9ba410
>> [ 3.405969] a05fc1bc bbff28dc 00000000 bb03dc70 a02b7fb9 bb03dce0
>> ba9ba410 a0579044
>>
>> into this:
>> [ 3.056825] Stack:
>> [ 3.056963] a04ebb20
>> [ 3.056995] bb03dc10
>> [ 3.057138] 00000001
>> [ 3.057277] bb03dc10
>> [ 3.057815] a00083ca
>> [ 3.057965] bb03dc50
>> [ 3.058107] ba9ba410
>> [ 3.058247] 37c3f000
>> [ 3.058387]
>> [ 3.058584] a05773e2
>> [ 3.058614] 00000001
>> [ 3.058755] a05ca0bc
>> [ 3.058896] bb03dc30
>> [ 3.059035] a000865c
>> [ 3.059180] bb03dc70
>> [ 3.059319] ba9ba410
>> [ 3.059459] 37c3f000
>> [ 3.059598]
>> [ 3.059795] 37c3f000
>> [ 3.059824] d7c3f000
>> [ 3.059964] 00000800
>> [ 3.060103] bb03dc50
>> [ 3.060241] a02b9809
>> [ 3.060379] bb03dc90
>> [ 3.060519] ba9ba400
>> [ 3.060658] ba9ba410
>> [ 3.060796]
Hey Max,
thanks for the testing and the report - will fix it in v2.
Thanks,
Dmitry
Powered by blists - more mailing lists