Le 14/02/2022 à 16:31, Christophe Leroy a écrit :
Le 14/02/2022 à 16:10, David Laight a écrit :
From: Christophe Leroy
Sent: 14 February 2022 14:58
...
I make that 3 extra instructions.
Two are needed to load the format string.
Not sure why the third gets added.
Third instruction is 'twui', to 'trap' and get the warning oops.
I wondered what that did :-)
Although you really want the -- cut here -- to contain the pr_warn().
Doesn't WARN() do that for you?
I remember some discussion about that in the past. Will dig into it
tomorrow.
I was looking at that last week because the 'scheduling while atomic'
trace is "BUG: xxxx" but doesn't have the '--- cut here --" marker.
So I looked at it. Both WARN_ON() and WARN() properly display the cut
here line:
WARN(1, "Testing whether cut here is there");
[ 35.051548] ------------[ cut here ]------------
[ 35.051611] Testing whether cut here is there
[ 35.051665] WARNING: CPU: 0 PID: 358 at
arch/powerpc/kernel/setup-common.c:330 show_cpuinfo+0x234/0x30c
WARN_ON(1);
[ 35.058987] ------------[ cut here ]------------
[ 35.059033] WARNING: CPU: 0 PID: 358 at
arch/powerpc/kernel/setup-common.c:331 show_cpuinfo+0x2b0/0x30c
So yes WARN() prints the "cut here", but what the 'twui' provides you is
everything else, the dump of all registers, call trace, instruction
dump, etc ...
The 'twui' is after the call to __warn_printk() so everything is after
the 'cut here'.
Then I'm not sure I understood your question.
The 'scheduling while atomic' is not generated by a WARN() but by a
printk in function __schedule_bug() hence the absence of '--- cut here ---'
Thanks
Christophe
