Segher Boessenkool [off-list ref] writes:

On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote:

quoted

Le 06/12/2019 à 21:59, Segher Boessenkool a écrit :

quoted

If the compiler can see the callee wants the same TOC as the caller has,
it does not arrange to set (and restore) it, no.  If it sees it may be
different, it does arrange for that (and the linker then will check if
it actually needs to do anything, and do that if needed).

In this case, the compiler cannot know the callee wants the same TOC,
which complicates thing a lot -- but it all works out.

Do we have a way to make sure which TOC the functions are using ? Is 
there several TOC at all in kernel code ?

Kernel modules have their own TOC, I think?

Yes.

quoted

quoted

I think things can still go wrong if any of this is inlined into a kernel
module?  Is there anything that prevents this / can this not happen for
some fundamental reason I don't see?

This can't happen can it ?
do_softirq_own_stack() is an outline function, defined in powerpc irq.c
Its only caller is do_softirq() which is an outline function defined in 
kernel/softirq.c

That prevents inlining, doesn't it ?

Hopefully, sure.  Would be nice if it was clearer that this works...  It
is too much like working by chance, the way it is :-(

There's no way any of that code can end up in a module. Or at least if
there is, that's a bug.

quoted

Anyway, until we clarify all this I'll limit my patch to PPC32 which is 
where the real benefit is I guess.

At the end, maybe the solution should be to switch to IRQ stack 
immediately in the exception entry as x86_64 do ?

Yeah that might be cleaner.

cheers