module loading issue/flaw in busy memory situation?

[Wrobel Heinz-R39252]

Hi,

let's assume a module gets loaded into an already busy system, and the ".init.text" section with the __init function gets loaded into one memory region, and the normal ".text" section gets loaded into a totally different memory region.
Now assume that both regions are >32MB apart in addressing, so that a call from the __init .init.text function to any function in .text requires a trampoline as set up by the do_plt_call() function in arch/kernel/module*.c
So far so good for user code.

Now assume that the __init function is not trivial and will require register save/restore functions in prologue/epilogue with such calls generated by gcc, e.g., the __init function calls _rest32gpr_28_x() in the epilogue. This restore functions however is in the .text section due to the static link of the normal libs.

Now we have the __init function calling the trampoline, which is destroying r11. The trampoline is then jumping to the register restore function which relies on r11 still being intact, which it now isn't anymore.
Net result is a crash because the trampoline ABI conflicts with the register restore ABI and you get a case of garbage in leading to garbage out.

This situation has apparently occurred based on the debug results I have here.

In the general case of module development it seems unpredictable if gcc will actually call a register restore function from the __init function, or if the sections get loaded to require a trampoline, so for any non-trivial function in non-trivial memory setups, a crash would have to be expected, depending on the time of day and moon phase when the module gets loaded.

Is this a fundamental flaw in the interaction of the module section use specification and the module load mechanism with the ABI definition?

Or am I missing some incorrect setup or requirement for __init functions that I should deal with?

Thanks,

Heinz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20120524/c55da39e/attachment-0001.html>