Re: [PATCH v6] mm: Uninline copy_overflow()

[Christophe Leroy]

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