From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D44132D9797 for ; Thu, 7 May 2026 08:05:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778141144; cv=none; b=BxGJFVqZhlMnSLGF+VmxAjS1/Y3/wjXsXjOak4F+R/VrF13+Z8iFe//v0Y0eMPXUXxZadu92Pei4ZUywjI4b05kydlHiCkODz3FeLFtWwbP3ffExmhpb950I9hMXIYoTGeCYkWYAv6m9yuo3lzvqI5+i92e5c/vfGt+UtN/VbyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778141144; c=relaxed/simple; bh=f6YYCCSQFMn/YGHb4l0kIACUIpEU2ZhLJwhEemDhlXE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iaqSLwLNQjrmDttumhAEAQl9VTVhjMPrFW4HPI8Z2e1RXxruRPBlwaKKqFgaSjnELuearhgMGDSW6woBMcEaVhiczuEuIZbEoLefyN5nO0jUH46Bghd+PzNxLpENE9E1/abL7YnnB0E+FM/krPUh+IntbJE3JuFQNRKRsdXud08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lPL8crFv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lPL8crFv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C006AC2BCB8; Thu, 7 May 2026 08:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778141144; bh=f6YYCCSQFMn/YGHb4l0kIACUIpEU2ZhLJwhEemDhlXE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lPL8crFv5xG8/WXgcMHeSVVwRdBj3v7V7f8Gwa0CE06C4HPsk42e3OTLpUibnVhJl WNNdIEGKxXxQu0UqExdSO8qPzLiXj0mtx9af11yJ6z0f+xIBCJ3LpaBo9NzN5ayLyZ iQw24pFxCb2hdbp3AkNN++PqdhicYIHfyLdzZiCL9xgvRG/iGaatDCXPzpPoi9Y031 ZvZ1VBMGb3E+9aGhOzZB5GUV9K4pvdkwEy0fbjajBOKjxpY2A70OMcb/NGRwcv7g6F B6zNXhBimndgloeCAmFInufvbD0mbkr6tMsRulvO1ZFGW2te3WwmeUsIf3FU1mWPx6 M+M+xMA2qSzTw== Date: Thu, 7 May 2026 10:05:39 +0200 From: Ingo Molnar To: Andy Shevchenko Cc: David Gow , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Andy Shevchenko , Arnd Bergmann , Nikolay Borisov , "H . Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86/boot/e820: Re-enable fallback if e820 table is empty Message-ID: References: <20260416065746.1896647-1-david@davidgow.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: * Andy Shevchenko wrote: > On Thu, Apr 16, 2026 at 02:57:43PM +0800, David Gow wrote: > > 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(). > > > > In so doing, we also update the return values to be proper error codes, > > with -ENOENT for this case (there are no entries), and -EINVAL for the case > > where an entry appears invalid. Given none of the callers check the actual > > value -- just whether it's nonzero -- this is largely aesthetic in > > practice. > > > > Tested against linld, and the kernel boots again fine. > > ... > > > Changes since v2: > > https://lore.kernel.org/lkml/20260415003021.1543723-1-david@davidgow.net/ > > - Return -ENOENT instead of -1 > > - Return -EINVAL instead of -1 for the case where an entry looks invalid due to > > an overflow (Thanks, Andy) > > Oh, I didn't noticed it's overflow condition, so -ERANGE may suit better. > Whatever, the change looks good enough and it's up to you to follow the above. > > Reviewed-by: Andy Shevchenko Applied, thanks! Ingo