[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-4.22] EFI: Fix boot from a device without a file system





On 5/19/26 3:45 PM, Andrew Cooper wrote:
On 19/05/2026 2:41 pm, Marek Marczykowski-Górecki wrote:
On Tue, May 19, 2026 at 03:06:57PM +0200, Szymon Acedański wrote:
When netbooting a unified Xen kernel image (via GRUB chainloader),
the resulting loaded_image->DeviceHandle does not support
SIMPLE_FILE_SYSTEM_PROTOCOL.

Instead of crashing via noreturn PrintErrMesg(), print a message
via PrintStr() and return NULL from get_parent_handle().
It's worth noting this isn't the first instance of returning NULL from
get_parent_handle(). The return value is used only as an argument
to read_file() (sometimes indirectly), and if it gets to be called with
NULL, read_file() will terminate execution via PrintErrMesg(). But with
unified Xen image, the intention is to not call read_file() at all, only
read_section(), so tolerating get_parent_handle() failure in this case
is desired. Keeping the message in place will ease debugging if
read_file() will actually be called later.

Acked-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

As a side note, a slightly better approach would be to call
get_parent_handle() lazily (on the first call to read_file()?). But it's
a bigger change that I feel may be too late for in Xen 4.22.

Also, adding cc: Oleksii for release ack.

Bugfixes are still fine to go in.

Personally, I think moving the call to get_parent_handle() is a better
fix, and fine for 4.22 even at this juncture.  ARM already does
something along these lines in allocate_module_file().

I agree that we could consider suggested better approach and I am okay with having this patch (or its new version) as part of 4.22.

Thanks.

~ Oleksii



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.