Hi Ilias, On Wed, 14 Aug 2024 at 07:07, Ilias Apalodimas <[email protected]> wrote: > > Hi Simon > > On Wed, 14 Aug 2024 at 15:40, Simon Glass <[email protected]> wrote: > > > > Hi Ilias, > > > > On Wed, 14 Aug 2024 at 05:03, Ilias Apalodimas > > <[email protected]> wrote: > > > > > > Hi Simon, > > > > > > On Thu, 1 Aug 2024 at 20:36, Simon Glass <[email protected]> wrote: > > > > > > > > Currently this calls efi_alloc() which reserves a page for each > > > > allocation and this can overwrite memory that will be used for reading > > > > images. > > > > > > > > Switch the code to use malloc(), as with other parts of EFI, such as > > > > efi_add_protocol(). > > > > > > > > Signed-off-by: Simon Glass <[email protected]> > > > > --- > > > > > > > > (no changes since v1) > > > > > > What about > > > https://lore.kernel.org/u-boot/caflsztjlakayk_jlxj7z571l-qmtoiqe-oxhcrs186dz2qo...@mail.gmail.com/ > > > ? > > > > Yes, I reordered the patches in this series. > > You don't need to reorder them. As Heinrich already pointed out some > of these functions are used in EFI protocols. e.g > duplicate_device_path() requires the memory to be allocated by EFI > memory services, you can't just replace it with malloc.
The pointers returned can be freed with EFI services. I don't see any problem here. All the tests pass and all the spec rules are followed, so far as I can tell. Bear in mind that I am changing the *implementation* of some memory routines, but not in a way that is visible to clients. I will send a v2 with things split up a bit more, so long as we remember that the EFI patches cannot be applied until the non-EFI patches land. Regards, Simon
