All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Kelley <mikelley@microsoft.com>,
	James Morris <jmorris@namei.org>, Sasha Levin <sashal@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>, x86-ml <x86@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	James Morris <James.Morris@microsoft.com>
Subject: Re: [GIT PULL] x86/urgent for v5.13-rc5
Date: Tue, 8 Jun 2021 22:01:50 +0200	[thread overview]
Message-ID: <YL/MoOZFRwo261WG@zn.tnic> (raw)
In-Reply-To: <CAHk-=wh1nz4=72vk3+q5TuPwBF2HMY4SnBOZr6WSLp=s4KExSA@mail.gmail.com>

On Tue, Jun 08, 2021 at 12:22:50PM -0700, Linus Torvalds wrote:
> On Tue, Jun 8, 2021 at 11:33 AM Borislav Petkov <bp@alien8.de> wrote:
> >
> > Linus, maybe we should at least give it a try and see whether someone
> > complains and revert, potentially...?
> 
> I already merged the change that did that.

Oh yeah, I meant: let's leave it in and try it and only revert if there's
trouble.

> It might be worth adding a comment about the verified Windows behavior
> here, but I think otherwise we're all done.

How's that (comment re-flowed):

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1e720626069a..b58cdc70f86b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1084,17 +1084,18 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	/*
-	 * Find free memory for the real mode trampoline and place it
-	 * there.
-	 * If there is not enough free memory under 1M, on EFI-enabled
-	 * systems there will be additional attempt to reclaim the memory
-	 * for the real mode trampoline at efi_free_boot_services().
+	 * Find free memory for the real mode trampoline and place it there. If
+	 * there is not enough free memory under 1M, on EFI-enabled systems
+	 * there will be additional attempt to reclaim the memory for the real
+	 * mode trampoline at efi_free_boot_services().
 	 *
-	 * Unconditionally reserve the entire first 1M of RAM because
-	 * BIOSes are know to corrupt low memory and several
-	 * hundred kilobytes are not worth complex detection what memory gets
-	 * clobbered. Moreover, on machines with SandyBridge graphics or in
-	 * setups that use crashkernel the entire 1M is reserved anyway.
+	 * Unconditionally reserve the entire first 1M of RAM because BIOSes
+	 * are known to corrupt low memory and several hundred kilobytes are not
+	 * worth complex detection what memory gets clobbered. Windows does the
+	 * same thing for very similar reasons.
+	 *
+	 * Moreover, on machines with SandyBridge graphics or in setups that use
+	 * crashkernel the entire 1M is reserved anyway.
 	 */
 	reserve_real_mode();
 

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2021-06-08 20:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06  7:55 [GIT PULL] x86/urgent for v5.13-rc5 Borislav Petkov
2021-06-06 19:38 ` Linus Torvalds
2021-06-06 20:58   ` Mike Rapoport
2021-06-06 21:23     ` Linus Torvalds
2021-06-06 22:07       ` Borislav Petkov
2021-06-06 23:05         ` Sasha Levin
2021-06-07 18:46           ` James Morris
2021-06-08 17:53             ` Michael Kelley
2021-06-08 18:33               ` Borislav Petkov
2021-06-08 19:22                 ` Linus Torvalds
2021-06-08 20:01                   ` Borislav Petkov [this message]
2021-06-08 20:03                     ` Linus Torvalds
2021-06-08 20:30                       ` [PATCH] x86/setup: Document that Windows reserves the first MiB Borislav Petkov
2021-06-09  8:54                         ` Mike Rapoport
2023-03-02 16:14               ` [GIT PULL] x86/urgent for v5.13-rc5 Andy Lutomirski
2023-03-02 21:17                 ` Michael Kelley (LINUX)
2021-06-06 20:14 ` pr-tracker-bot

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=YL/MoOZFRwo261WG@zn.tnic \
    --to=bp@alien8.de \
    --cc=James.Morris@microsoft.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=rppt@linux.ibm.com \
    --cc=sashal@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.