mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ross Philipson <ross.philipson@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	daniel.kiper@oracle.com, dpsmith@apertussolutions.com,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	luto@amacapital.net, kanth.ghatraju@oracle.com,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH 1/2] x86/boot: Fix memremap of setup_indirect structures
Date: Tue, 15 Feb 2022 19:37:38 +0100	[thread overview]
Message-ID: <Ygvy8j9E7WPo6dx0@zn.tnic> (raw)
In-Reply-To: <2e584fc4-163a-0af4-abe0-9c14996918f2@oracle.com>

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

  reply	other threads:[~2022-02-15 18:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 17:04 [PATCH 0/2] x86/boot: Fix setup_indirect support Ross Philipson
2022-01-27 17:04 ` [PATCH 1/2] x86/boot: Fix memremap of setup_indirect structures Ross Philipson
2022-02-11 17:24   ` Borislav Petkov
2022-02-15 11:34     ` Ross Philipson
2022-02-15 18:37       ` Borislav Petkov [this message]
2022-02-22 21:01         ` Ross Philipson
2022-02-24 13:42           ` Borislav Petkov
2022-02-24 15:13             ` Ross Philipson
2022-01-27 17:04 ` [PATCH 2/2] x86/boot: Add setup_indirect support in early_memremap_is_setup_data Ross Philipson
2022-02-11 18:41   ` Borislav Petkov
2022-02-15 11:36     ` Ross Philipson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ygvy8j9E7WPo6dx0@zn.tnic \
    --to=bp@alien8.de \
    --cc=daniel.kiper@oracle.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=hpa@zytor.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®