In commit 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables"),
the check that the number of entries in the e820 table was removed. The
intention was to support single-entry maps, but by removing the check
entirely, we also skip the fallback (to, e.g., the BIOS 88h function).

This means that if no E820 map is passed in from the bootloader (which is
the case on some bootloaders, like linld), we end up with an empty memory
map, and the kernel fails to boot (either by deadlocking on OOM, or by
failing to allocate the real mode trampoline, or similar).

Re-instate the check in append_e820_table(), but only check nr_entries is
non-zero. This allows e820__memory_setup_default() to fall back to other
memory size sources, and doesn't affect e820__memory_setup_extended(), as
the latter ignores the return value from append_e820_table().

Tested against linld, and the kernel boots again fine.

Fixes: 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables")
Signed-off-by: David Gow <david@davidgow.net>
---
 arch/x86/kernel/e820.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 2a9992758933..7dfd4bdc95fb 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -450,6 +450,10 @@ __init static int append_e820_table(struct boot_e820_entry *entries, u32 nr_entr
 {
 	struct boot_e820_entry *entry = entries;
 
+	/* If there aren't any entries, we'll want to fall-back to another source. */
+	if (!nr_entries)
+		return -1;
+
 	while (nr_entries) {
 		u64 start = entry->addr;
 		u64 size  = entry->size;
-- 
2.53.0

On Wed, Apr 15, 2026 at 08:30:18AM +0800, David Gow wrote:
> In commit 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables"),

Note, it's fine to wrap this line in the commit message, it's only requirement
to tags to be "1 tag — 1 line".

> the check that the number of entries in the e820 table was removed. The
> intention was to support single-entry maps, but by removing the check
> entirely, we also skip the fallback (to, e.g., the BIOS 88h function).
> 
> This means that if no E820 map is passed in from the bootloader (which is
> the case on some bootloaders, like linld), we end up with an empty memory
> map, and the kernel fails to boot (either by deadlocking on OOM, or by
> failing to allocate the real mode trampoline, or similar).
> 
> Re-instate the check in append_e820_table(), but only check nr_entries is
> non-zero. This allows e820__memory_setup_default() to fall back to other
> memory size sources, and doesn't affect e820__memory_setup_extended(), as
> the latter ignores the return value from append_e820_table().
> 
> Tested against linld, and the kernel boots again fine.
> 
> Fixes: 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables")

...

>  	struct boot_e820_entry *entry = entries;
>  
> +	/* If there aren't any entries, we'll want to fall-back to another source. */
> +	if (!nr_entries)
> +		return -1;

Can we return -ENODATA or -ENOENT here?

-- 
With Best Regards,
Andy Shevchenko

Le 15/04/2026 à 4:51 PM, Andy Shevchenko a écrit :
> On Wed, Apr 15, 2026 at 08:30:18AM +0800, David Gow wrote:
>> In commit 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables"),
> 
> Note, it's fine to wrap this line in the commit message, it's only requirement
> to tags to be "1 tag — 1 line".
> 

Thanks -- I vaguely recall checkpatch complaining about this at some 
point, though I could've been imagining it...

>> the check that the number of entries in the e820 table was removed. The
>> intention was to support single-entry maps, but by removing the check
>> entirely, we also skip the fallback (to, e.g., the BIOS 88h function).
>>
>> This means that if no E820 map is passed in from the bootloader (which is
>> the case on some bootloaders, like linld), we end up with an empty memory
>> map, and the kernel fails to boot (either by deadlocking on OOM, or by
>> failing to allocate the real mode trampoline, or similar).
>>
>> Re-instate the check in append_e820_table(), but only check nr_entries is
>> non-zero. This allows e820__memory_setup_default() to fall back to other
>> memory size sources, and doesn't affect e820__memory_setup_extended(), as
>> the latter ignores the return value from append_e820_table().
>>
>> Tested against linld, and the kernel boots again fine.
>>
>> Fixes: 157266edcc56 ("x86/boot/e820: Simplify append_e820_table() and remove restriction on single-entry tables")
> 
> ...
> 
>>   	struct boot_e820_entry *entry = entries;
>>   
>> +	/* If there aren't any entries, we'll want to fall-back to another source. */
>> +	if (!nr_entries)
>> +		return -1;
> 
> Can we return -ENODATA or -ENOENT here?
> 

Sounds like a good idea. The previous code (like this) used -1 for both 
"there are no entires" and "there are entries which look bogus". Maybe 
we should replace the latter with -EINVAL, too.

-- David

On Wed, Apr 15, 2026 at 09:50:32PM +0800, David Gow wrote:
> Le 15/04/2026 à 4:51 PM, Andy Shevchenko a écrit :
> > On Wed, Apr 15, 2026 at 08:30:18AM +0800, David Gow wrote:

...

> > >   	struct boot_e820_entry *entry = entries;
> > > +	/* If there aren't any entries, we'll want to fall-back to another source. */
> > > +	if (!nr_entries)
> > > +		return -1;
> > 
> > Can we return -ENODATA or -ENOENT here?
> 
> Sounds like a good idea. The previous code (like this) used -1 for both
> "there are no entires" and "there are entries which look bogus". Maybe we
> should replace the latter with -EINVAL, too.

Maybe, but is it related to (coupled with) this change? If not, we can do it
later if needed.

-- 
With Best Regards,
Andy Shevchenko

Le 15/04/2026 à 10:26 PM, Andy Shevchenko a écrit :
> On Wed, Apr 15, 2026 at 09:50:32PM +0800, David Gow wrote:
>> Le 15/04/2026 à 4:51 PM, Andy Shevchenko a écrit :
>>> On Wed, Apr 15, 2026 at 08:30:18AM +0800, David Gow wrote:
> 
> ...
> 
>>>>    	struct boot_e820_entry *entry = entries;
>>>> +	/* If there aren't any entries, we'll want to fall-back to another source. */
>>>> +	if (!nr_entries)
>>>> +		return -1;
>>>
>>> Can we return -ENODATA or -ENOENT here?
>>
>> Sounds like a good idea. The previous code (like this) used -1 for both
>> "there are no entires" and "there are entries which look bogus". Maybe we
>> should replace the latter with -EINVAL, too.
> 
> Maybe, but is it related to (coupled with) this change? If not, we can do it
> later if needed.
> 

I think it's probably related enough: append_e820_table() only has the 
one other error return. That being said, I don't think it matters too 
much either way: there's exactly one caller which checks the return 
value, and it only cares that it's nonzero. We could just replace the 
whole thing with a bool. (Or, if we wanted to be more brave, with the 
count of entries added, though that'd complicate the caller a bit if we 
wanted to preserve the same behaviour.)

Regardless, I've sent out v2 here:
https://lore.kernel.org/all/20260416065746.1896647-1-david@davidgow.net/

Cheers,
-- David