On 5/18/2017 4:02 AM, Borislav Petkov wrote:
On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote:
I was worried what the compiler might do when CONFIG_EFI is not set,
but it appears to take care of it. I'll double check though.
There's a efi_enabled() !CONFIG_EFI version too, so should be fine.
I may introduce a length variable to capture data->len right after
paddr_next is set and then have just a single memunmap() call before
the if check.
Yap.
I tried that, but calling an "__init" function (early_memremap()) from
a non "__init" function generated warnings. I suppose I can pass in a
function for the map and unmap but that looks worse to me (also the
unmap functions take different arguments).
No, the other way around: the __init function should call the non-init
one and you need the non-init one anyway for memremap_is_setup_data().
The "worker" function would be doing the loop through the setup data,
but since the setup data is mapped inside the loop I can't do the __init
calling the non-init function and still hope to consolidate the code.
Maybe I'm missing something here...
Thanks,
Tom
This is like the chicken and the egg scenario. In order to determine if
an address is setup data I have to explicitly map the setup data chain
as decrypted. In order to do that I have to supply a flag to explicitly
map the data decrypted otherwise I wind up back in the
memremap_is_setup_data() function again and again and again...
Oh, fun.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
