[PATCH] efi_loader : Suppress error print message

Heinrich Schuchardt xypron.glpk at gmx.de
Tue Jan 23 11:00:23 CET 2024


On 1/23/24 09:33, Ilias Apalodimas wrote:
> Hi Tejas,
>
> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> <tejas.arvind.bhumkar at amd.com> wrote:
>>
>> Currently, on certain Xilinx platforms, an issue has been
>> identified, manifesting as follows:

Hello Tejas,

thank you for bringing forward this issue.

Which defconfig are you relating to?

>>
>> Starting kernel ...
>>
>> efi_free_pool: illegal free 0x0000000077830040
>> efi_free_pool: illegal free 0x000000007782d040
>> efi_free_pool: illegal free 0x000000007782c040
>>
>> The issue arises when the ramdisk image is relocated, placing
>> it within the previously allocated EFI memory region( as EFI
>> is established quite early in U-Boot).

Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider
EFI memory map") was meant to avoid such a situation.

>
> I don't mind suppressing the print for some time, but out of
> curiosity, how is the ramdisk relocated? LMB should be aware of the
> EFI regions by then, so I assume the relocation code doesn't check
> those?

The indicated situation is serious. If the EFI sub-system is using the
same memory area as the ramdisk, this may lead to corruption of the
ramdisk. Suppressing the messages is by no means adequate to solve the
problem.

Best regards

Heinrich


>
> Thanks
> /Ilias
>
>> Consequently, when
>> attempting to release memory in the EFI memory region during
>> the handover process to the kernel,we encounter memory violations.
>>
>> Highlighting that EFI remains active primarily during the
>> booting of an EFI application, and the lmb persists while
>> configuring images for the boot process. Since we aren't
>> utilizing the EFI memory region during the boot process,
>> there is no adverse impact even in the event of a violation.
>>
>> Currently, there is an ongoing discussion regarding the handling
>> strategies of three memory allocators: malloc, lmb, and EFI. This
>> discussion is documented in the email chain
>> titled "Proposal: U-Boot memory management."
>>
>> Therefore, it is advisable to suppress the print message during
>> the boot process for now.
>>
>> Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar at amd.com>
>> ---
>>   lib/efi_loader/efi_memory.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index edfad2d95a..821fe7616e 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer)
>>          /* Check that this memory was allocated by efi_allocate_pool() */
>>          if (((uintptr_t)alloc & EFI_PAGE_MASK) ||
>>              alloc->checksum != checksum(alloc)) {
>> -               printf("%s: illegal free 0x%p\n", __func__, buffer);
>> +               debug("%s: illegal free 0x%p\n", __func__, buffer);
>>                  return EFI_INVALID_PARAMETER;
>>          }
>>          /* Avoid double free */
>> --
>> 2.27.0
>>



More information about the U-Boot mailing list