From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 C9E2337C0FE for ; Thu, 16 Apr 2026 08:11:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776327082; cv=none; b=cs02EEmMR4hr9+6nkiClQMeFLL7fGW816DyBxYm9fhfZBey4zsbLYEy2OZ6AVxyyxx5rj6fA+oe3V8dLludVHZrtVgkwI9paMBXggvMnSDXiSWwKxhhZF9iu0+SsoKrjbmprSN+KvTDtqS+XSLLF3+I5hTzch+vTYeEKm/uRO1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776327082; c=relaxed/simple; bh=+qfLNBFeOHozwNaQwIKkCcIfT+jtGW7sqmx04eKiiWU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CIQJk3J93QAJSZQxCqr/TnajxpA4mfyWlA13Vgroez1P9n/Cklzo5W3kwve++e42d/w7ip61i46JXpd3xbhaY8OpVoWM93fIuUyeFDIuacNt7Eg5JLzPGZE7oyEeV/lKjyA8EXdWKri4hMCIiE29SF7if7vWAeCmpvEqE03Xjko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=j7kP9tKw; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="j7kP9tKw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776327080; x=1807863080; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+qfLNBFeOHozwNaQwIKkCcIfT+jtGW7sqmx04eKiiWU=; b=j7kP9tKwS7NVb7jzOgs5TFf6izQzNUIxSeeB0YI4vD3mmztke9YQoYxO tYr6/+wuLsy15wq1IOt2UMd7922uk/oUINmKoMX4qfOI9pmB9YVwv20Ni TvRfEFbEniYvt7cfSEYfoV0c6XcrA073n/XjTgjdJVr9+y2/rdAkj4KvB ZH6MoylgznQ48mZuu9Bukgkr8Gtmdc54mV8OgWSNsPmdQidqVueo4Bc9i Qu4d88MWe1jNpNFQVMCcsWBNuZzjqGRczHAgtY5fa6iKpxE5ExQOTpdzD WbfKrSxAI28EH4CCqHn3TukkVvXPdLqWzMnK2eZBUNotj9gw2tUSPKWuJ w==; X-CSE-ConnectionGUID: s10Pqw0ERbCAppsk9x/c8A== X-CSE-MsgGUID: jlQe3lIhSomXldffim1ENA== X-IronPort-AV: E=McAfee;i="6800,10657,11760"; a="77435305" X-IronPort-AV: E=Sophos;i="6.23,181,1770624000"; d="scan'208";a="77435305" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2026 01:11:20 -0700 X-CSE-ConnectionGUID: wHwyLfJTR42wAZaHFaWB0g== X-CSE-MsgGUID: O07d8fZDQRiiVsu/8IMyZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,181,1770624000"; d="scan'208";a="261092322" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost) ([10.245.244.173]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2026 01:11:18 -0700 Date: Thu, 16 Apr 2026 11:11:15 +0300 From: Andy Shevchenko To: David Gow Cc: Ingo Molnar , 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: <20260416065746.1896647-1-david@davidgow.net> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo 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 -- With Best Regards, Andy Shevchenko