diff mbox

powernv: Use _GLOBAL_TOC for opal wrappers

Message ID 1413948772.62479.492398078454.1.gpush@pablo (mailing list archive)
State Accepted
Delegated to: Michael Ellerman
Headers show

Commit Message

Jeremy Kerr Oct. 22, 2014, 3:32 a.m. UTC
Currently, we can't call opal wrappers from modules when using the LE
ABIv2, which requires a TOC init.

This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
opal wrappers, so that we can do non-local calls to them.

Signed-off-by: Jeremy Kerr <jk@ozlabs.org>

---
 arch/powerpc/platforms/powernv/opal-wrappers.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Michael Ellerman Oct. 22, 2014, 5:31 a.m. UTC | #1
On Wed, 2014-10-22 at 11:32 +0800, Jeremy Kerr wrote:
> Currently, we can't call opal wrappers from modules when using the LE
> ABIv2, which requires a TOC init.

What happens if we try? Build failure or run time bug?

> This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
> opal wrappers, so that we can do non-local calls to them.

Are we doing that now, or we would like to?

cheers
Benjamin Herrenschmidt Oct. 22, 2014, 6:10 a.m. UTC | #2
On Wed, 2014-10-22 at 16:31 +1100, Michael Ellerman wrote:
> On Wed, 2014-10-22 at 11:32 +0800, Jeremy Kerr wrote:
> > Currently, we can't call opal wrappers from modules when using the LE
> > ABIv2, which requires a TOC init.
> 
> What happens if we try? Build failure or run time bug?

Kaboom.

> > This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
> > opal wrappers, so that we can do non-local calls to them.
> 
> Are we doing that now, or we would like to?

We do now for a test module (the one that test using the invalid
OPAL call), but we would like to use it for real for the new IPMI
driver among others.

Cheers,
Ben.
Jeremy Kerr Oct. 22, 2014, 11:12 a.m. UTC | #3
Hi Michael,

>> Currently, we can't call opal wrappers from modules when using the LE
>> ABIv2, which requires a TOC init.
> 
> What happens if we try? Build failure or run time bug?

We'll get an arbitrary memory dereference (two, actually) in the opal
wrappers, when we try to load the opal entry point & return address from
the TOC, as r2 may not point to a valid TOC for the kernel.

>> This change uses the _GLOBAL_TOC() macro (rather than _GLOBAL) for the
>> opal wrappers, so that we can do non-local calls to them.
> 
> Are we doing that now, or we would like to?

We'd like to; although we do EXPORT_SYMBOL on another wrapper
(opal_invalid_call()) already. From the call name though, I figure it's
not in any mission-critical usage :)

Cheers,


Jeremy
diff mbox

Patch

diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e9e2450..845a5c5 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -58,7 +58,7 @@  END_FTR_SECTION(0, 1);						\
  */
 
 #define OPAL_CALL(name, token)		\
- _GLOBAL(name);				\
+ _GLOBAL_TOC(name);				\
 	mflr	r0;			\
 	std	r0,16(r1);		\
 	li	r0,token;		\