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. >
