kernel panic during kernel module load (powerpc specific part)

[Steffen Rumler]

> On Fri, Jun 01, 2012 at 11:33:37AM +0000, Wrobel Heinz-R39252 wrote:
>>>> I believe that the basic premise is that you should provide a directly
>>>> reachable copy of the save/rstore functions, even if this means that
>>> you need several copies of the functions.
>>>
>>> I just fixed a very similar problem with grub2 in fact. It was using r0
>>> and trashing the saved LR that way.
>>>
>>> The real fix is indeed to statically link those gcc "helpers", we
>>> shouldn't generate things like cross-module calls inside function prologs
>>> and epilogues, when stackframes aren't even guaranteed to be reliable.
>>>
>>> However, in the grub2 case, it was easier to just use r12 :-)
>> For not just the module loading case, I believe r12 is the only real solution now. I checked one debugger capable of doing ELF download. It also uses r12 for trampoline code. I am guessing for the reason that prompted this discussion.
>>
> I disagree. Look carefully at Be's answer: cross-module calls
> are intrinsically dangerous when stack frames are in a transient
> state.
>
>> Without r12 we'd have to change standard libraries to automagically link in gcc helpers for any conceivable non-.text section, which I am not sure is feasible. How would you write section independent helper functions which link to any section needing them?!
> I don't thnk that it is tha bad: the helpers should be linked to the default .text section
> when needed, typically the init code and so on are mapped within the reach of that
> section (otherwise you'll end up with the linker complaining that it finds overflowing
> branch offsets between .text and .init.text).
>
>> Asking users to create their own section specific copy of helper functions is definitely not portable if the module or other code is not architecture dependent.
> Well, it automagically works on 64 bit. There is is performed by magic built into the linker.
>
>> It is a normal gcc feature that you can assign specific code to non-.text sections and it is not documented that it may crash depending on the OS arch the ELF is built for, so asking for a Power Architecture specific change on tool libs to make Power Architecture Linux happy seems a bit much to ask.
>>
> Once again I disagree.
>
>> Using r12 in any Linux related trampoline code seems a reachable goal, and it would eliminate the conflict to the ABI.
>>
> There is no conflict to the ABI. These functions are supposed to be directly reachable from whatever code
> section may need them.
>
> Now I have a question: how did you get the need for this?
>
> None of my kernels uses them:
> - if I compile with -O2, the compiler simply expands epilogue and prologue to series of lwz and stw
> - if I compile with -Os, the compiler generates lmw/stmw which give the smallest possible cache footprint
>
> Neither did I find a single reference to these functions in several systems that I grepped for.
>
> 	Regards,
> 	Gabriel
>
Hi,

how should we continue here ?
There is the kernel panic, I've described.

Technically, there is an conflict between the code generated by the compiler and the loader in module_32.c, at least by using -Os.
Because the prologue/epilogue is part of the .text and init_module() is part of .init.text (in the case __init is applied, as usual),
a directly reachable call is not always possible.

Thanks
Steffen