public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Ashok Raj <ashok.raj@intel.com>, Borislav Petkov <bp@alien8.de>
Cc: Ashok Raj <ashok.raj@intel.com>, Tony Luck <tony.luck@intel.com>,
	LKML <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Stefan Talpalaru <stefantalpalaru@yahoo.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Peter Zilstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH v1 Part2 1/5] x86/microcode: Move late load warning to the same function that taints kernel
Date: Thu, 19 Jan 2023 22:48:30 +0100	[thread overview]
Message-ID: <875yd2i4b5.ffs@tglx> (raw)
In-Reply-To: <20230113172920.113612-2-ashok.raj@intel.com>

On Fri, Jan 13 2023 at 09:29, Ashok Raj wrote:
> Currently the warning about late loading and tainting are issued from two
> different functions.
>
> Later patches will re-enable microcode late-loading.
>
> Having both messages in the same function helps issuing warnings only
> when required.
>
> Move the warning from microcode_reload_late() -> reload_store() where the
> kernel tainting also happens.
>
> No functional change.

I had to read this more than once to make sense of it. Let me try a
translation:

  Late microcode loading issues a warning and taints the
  kernel. Tainting the kernel and emitting the warning happens in two
  different functions.

  The upcoming support for safe late loading under certain conditions
  needs to prevent both the warning and the tainting when the safe
  conditions are met. That would require to hand the result of the safe
  condition check into the function which emits the warning.

  To avoid this awkward construct, move the warning into reload_store()
  next to the taint() invocation as that is also the function which will
  later contain the safe condition check.

  No functional change.

Did my decoder get that right?

Thanks,

        tglx

  reply	other threads:[~2023-01-19 22:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 17:29 [PATCH v1 Part2 0/5] Declare safe late loadable microcode Ashok Raj
2023-01-13 17:29 ` [PATCH v1 Part2 1/5] x86/microcode: Move late load warning to the same function that taints kernel Ashok Raj
2023-01-19 21:48   ` Thomas Gleixner [this message]
2023-01-19 22:05     ` Ashok Raj
2023-01-13 17:29 ` [PATCH v1 Part2 2/5] x86/microcode/intel: Add minimum required revision to microcode header Ashok Raj
2023-01-19 22:03   ` Thomas Gleixner
2023-01-19 22:34     ` Ashok Raj
2023-01-13 17:29 ` [PATCH v1 Part2 3/5] x86/microcode: Add a generic mechanism to declare support for minrev Ashok Raj
2023-01-20  0:15   ` Thomas Gleixner
2023-01-20  2:19     ` Ashok Raj
2023-01-21 21:35     ` [Part 2 v2[cleanup] 0/4] Some additional cleanups in microcode Ashok Raj
2023-01-21 21:35       ` [Part 2 v2[cleanup] 1/4] x86/microcode: Taint kernel only if microcode loading was successful Ashok Raj
2023-01-21 21:35       ` [Part 2 v2[cleanup] 2/4] x86/microcode: Report invalid writes to reload sysfs file Ashok Raj
2023-01-21 21:35       ` [Part 2 v2[cleanup] 3/4] x86/microcode/intel: Fix collect_cpu_info() to reflect current microcode Ashok Raj
2023-01-21 21:35       ` [Part 2 v2[cleanup] 4/4] x86/microcode: Do not call apply_microde() on sibling threads Ashok Raj
2023-01-22  3:36         ` Ashok Raj
2023-01-26 16:52       ` [Part 2 v2[cleanup] 0/4] Some additional cleanups in microcode Ashok Raj
2023-01-27 13:49         ` Borislav Petkov
2023-01-13 17:29 ` [PATCH v1 Part2 4/5] x86/microcode/intel: Drop wbinvd() from microcode loading Ashok Raj
2023-01-13 17:29 ` [PATCH v1 Part2 5/5] x86/microcode: Provide an option to override minrev enforcement Ashok Raj

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=875yd2i4b5.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=alison.schofield@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=stefantalpalaru@yahoo.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.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