On Fri, 25 Sep 2026, at 14:59, Jason Gunthorpe wrote:
> On Thu, Sep 24, 2026 at 03:49:02PM -0700, Jonathan Cameron wrote:
>> On Thu, 24 Sep 2026 10:53:06 -0300
>> Jason Gunthorpe <[email protected]> wrote:
>>
>> > Sashiko points out that efi_handle_cmdline() allocates this memory and
>> > hands it over to the caller. If efi_pe_entry() ever returns it should be
>> > freed. Add a __free annotation.
>> >
>> > Fixes: 42c8ea3dca09 ("efi: libstub: Factor out EFI stub entrypoint into
>> > separate file")
>> > Signed-off-by: Jason Gunthorpe <[email protected]>
>> > ---
>> > drivers/firmware/efi/libstub/efi-stub-entry.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c
>> > b/drivers/firmware/efi/libstub/efi-stub-entry.c
>> > index aa85e910fe595e..83fade2b0d3b84 100644
>> > --- a/drivers/firmware/efi/libstub/efi-stub-entry.c
>> > +++ b/drivers/firmware/efi/libstub/efi-stub-entry.c
>> > @@ -40,7 +40,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
>> > unsigned long image_addr;
>> > unsigned long image_size = 0;
>> > /* addr/point and size pairs for memory management*/
>> > - char *cmdline_ptr = NULL;
>> > + char *cmdline_ptr __free(efi_pool) = NULL;
>>
>> Can we move this down to just above the call to efi_handle_cmdline that
>> does the constructor side of this?
>>
>> I see none of the efi stuff follow those guidance note that went in
>> cleanup.h.
>
My bad. Patches welcome.
> Yeah, I stuck with what was there.. It looks kind of weird that way:
>
> char *cmdline_ptr __free(efi_pool) = NULL;
> status = efi_handle_cmdline(image, &cmdline_ptr);
> if (status != EFI_SUCCESS)
> return status;
>
That looks fine, no?
