Thread (6 messages) 6 messages, 3 authors, 2015-10-19

Re: [PATCH] rtas: Validate rtas entry before calling enter_rtas

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2015-10-19 09:41:54

On Sat, 2015-10-17 at 10:04 +0530, Vasant Hegde wrote:
On 10/16/2015 11:49 PM, Denis Kirjanov wrote:
quoted
On 10/16/15, Vasant Hegde [off-list ref] wrote:
quoted
On 10/16/2015 04:02 PM, Denis Kirjanov wrote:
quoted
On 10/16/15, Vasant Hegde [off-list ref] wrote:
quoted
Currently we do not validate rtas entry before calling enter_rtas().
have you figured out why we have null entry?
quoted
quoted
Yes... On PowerNV platform we don't have RTAS.. Hence it's not initialized.
quoted
But why do we have CONFIG_PPC_RTAS on OPAL machines then?
 
Today we use single config to build kernel for both PowerNV and PAPR guest. So
that same ISO can be used in different environment (PAPR LPAR, PowerNV host,
guest). I believe most distro also following this method. Hence we need this
validation.
Yes that's right.

Many of our platforms can coexist. So for example you can build a 64-bit big
endian kernel with support for G5, pSeries, Powernv, PS3, IBM Cell Blades,
Pasemi, & Maple (Bimini).

That means code that is #ifdef'ed to depend on one of those platforms, may end
up running on another platform. So we usually also need a runtime check to make
sure code doesn't run in the wrong places.

You'll see a lot of initcalls are machine_xxx_initcalls(), which means they
only run if the correct platform was detected. There's also
firmware_has_feature() checks, and then also device tree based detection.

This one seems to have slipped through the cracks because the tools that call
sys_rtas() are not used on powernv machines, so no one has though to call that
syscall. And on pseries machines rtas is always present, though obviously the
code should have still checked rtas.entry to be safe.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help