On 1 August 2018 at 22:49, Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote:
>
>> On Aug 1, 2018, at 11:33 AM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>>
>> On 1 August 2018 at 19:07, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote:
>>> On 8/1/2018 10:27 AM, Eric Snowberg wrote:
>>>> Once EBS is called, there isn’t enough room available for the new memory
>>>> map on a very large system (do to the memory that was previously allocated
>>>> in exit_boot_func).
>>>>
>>>> The race condition that exists between priv_func and the call to EBS will
>>>> be taken care of by the existing code, thru the slack slots.
>>>
>>>
>>> Now I'm slightly confused. There isn't an issue because of slack slots?
>>>
>>> I'm kind of wondering if our assumption that 8 slots would be enough is not
>>> invalid, and therefore we need to increase that number. I hate kicking the
>>> can down the road like that, but as discussed in 2016, there doesn't seem to
>>> be a good alternative.
>>>
>>
>> But why does alloc_e820ext have to be deferred to the last minute?
>
> I didn’t understand that either. If it was done earlier, I assume there would not be a problem.
>
> Our tests show any kernel prior to Commit d64934019f6c ("x86/efi: Use efi_exit_boot_services()”) will boot successfully. The first "goto get_map" that was removed from the previous exit_boot insured their was enough room for the memory map when EBS was called.
>
> Which would you rather see done? Increase the slack number or move the e820 code? I can look at doing either if you'd like.
>
Given that this is a peculiarity of the x86 code, I'd prefer it if we
could fix it there as well.
--
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
