[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ygvy8j9E7WPo6dx0@zn.tnic>
Date: Tue, 15 Feb 2022 19:37:38 +0100
From: Borislav Petkov <bp@...en8.de>
To: Ross Philipson <ross.philipson@...cle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
daniel.kiper@...cle.com, dpsmith@...rtussolutions.com,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
luto@...capital.net, kanth.ghatraju@...cle.com,
trenchboot-devel@...glegroups.com
Subject: Re: [PATCH 1/2] x86/boot: Fix memremap of setup_indirect structures
On Tue, Feb 15, 2022 at 06:34:43AM -0500, Ross Philipson wrote:
> It can if you run out of slots in the fixed map.
Right. Or if any of the checks in __early_ioremap() fail. But those
would at least warn.
> The only reason I did not check it for NULL was because it was not
> checked elsewhere for NULL.
Elsewhere in the tree or elsewhere in this file or in the setup_indirect
adding code?
> I guess there are two questions:
>
> 1. Should I also fix it elsewhere in the code I am touching?
Yes pls.
> 2. What should I do on an allocation failure? In a routine like this it
> seems to be a critical early boot failure.
How so?
I'd expect in the case of e820__reserve_setup_data(), for example, to
not call e820__range_update* and not have those indirect ranges present
in the e820 map. What the user intended might not work but it'll at
least boot instead of floating dead in the water.
And similar approach in the other places you're touching.
You could even issue a warning or so so that users at least know what's
going on. I'd say...
> I guess the original intention might have been to let it just blow up
> since there is no recovery but that is just conjecture...
The original intention?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists