Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier

From: Juergen Gross
Date: Mon Sep 20 2021 - 02:00:58 EST


On 19.09.21 19:15, Borislav Petkov wrote:
On Sun, Sep 19, 2021 at 06:55:16PM +0200, Mike Galbraith wrote:
On Thu, 2021-09-16 at 10:50 +0000, tip-bot2 for Juergen Gross wrote:
The following commit has been merged into the x86/urgent branch of
tip:

Commit-ID:     1c1046581f1a3809e075669a3df0191869d96dd1
Gitweb:
https://git.kernel.org/tip/1c1046581f1a3809e075669a3df0191869d96dd1
Author:        Juergen Gross <jgross@xxxxxxxx>
AuthorDate:    Tue, 14 Sep 2021 11:41:08 +02:00
Committer:     Borislav Petkov <bp@xxxxxxx>
CommitterDate: Thu, 16 Sep 2021 12:38:05 +02:00

x86/setup: Call early_reserve_memory() earlier

This commit rendered tip toxic to my i4790 desktop box and i5-6200U
lappy. Boot for both is instantly over without so much as a twitch.

Post bisect revert made both all better.

I had a suspicion that moving stuff around like that would not just
simply work in all cases, as our boot order is very lovely and fragile.

And it booted just fine on my machines here.

;-\

Anyway, commit zapped from the x86/urgent lineup. We'll have to have a
third try later.


How will that try look like? I'm seeing the following alternatives:

1. Just revert a799c2bd29d19c565 ("x86/setup: Consolidate early memory
reservations").

2. Try to move the call of early_reserve_memory() just before the call
of e820__memory_setup().

3. Split early_reserve_memory() into two parts, with the first part
doing the memblock_reserve() calls for the kernel text, initrd and
page 0 right at the start of setup_arch(), and the second part for
the rest at the same place it is handled now.

4. Analyze why Mike's systems fail to boot and try to fix his issue(s)
(probably via one of the above ways).

Looking at the calls done in early_reserve_memory() I have my doubts
that memblock_x86_reserve_range_setup_data() will work before
early_ioremap_init() has been called, as it is using early_memremap().
This would suggest variant 2 could be a working solution.

In case I'm wrong with my doubts I'd prefer variant 3.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature