public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
* Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
@ 2024-12-17 15:32 Thomas De Schampheleire
  2024-12-17 15:53 ` Greg KH
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2024-12-17 15:32 UTC (permalink / raw)
  To: stable; +Cc: Borislav Petkov (AMD)

Hello,

Below commit was ported to 6.12, but I would like to request porting to the 6.6
longterm branch we are currently using:

    commit c809b0d0e52d01c30066367b2952c4c4186b1047
    Author: Borislav Petkov (AMD) <bp@alien8.de>
    Date:   2024-11-19 12:21:33 +0100

        x86/microcode/AMD: Flush patch buffer mapping after application
        [...]


The patch itself is small, but the consequence of not patching is large on
affected systems (tens of seconds to minutes, of boot delay). See original
discussion [1] for details.

The patch in master relies on a variable 'bsp_cpuid_1_eax' introduced in commit
94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the
patch ID"), but porting that entire commit seems excessive, especially because
there are several 'Fixes' commits for that one (e.g. 5343558a868e, d1744a4c975b,
1d81d85d1a19).

I think the simplest prerequisite change is (for Borislav Petkov to confirm):

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index bbd1dc38ea03..555fa76bd1f3 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -96,6 +97,8 @@ struct cont_desc {
 
 static u32 ucode_new_rev;
 
+static u32 bsp_cpuid_1_eax __ro_after_init;
+
 /*
  * Microcode patch container file is prepended to the initrd in cpio
  * format. See Documentation/arch/x86/microcode.rst
@@ -551,6 +566,7 @@ static void apply_ucode_from_containers(unsigned int cpuid_1_eax)
 
 void load_ucode_amd_early(unsigned int cpuid_1_eax)
 {
+	bsp_cpuid_1_eax = cpuid_1_eax;
 	return apply_ucode_from_containers(cpuid_1_eax);
 }
 


Thanks,
Thomas

[1] https://lore.kernel.org/lkml/ZyulbYuvrkshfsd2@antipodes/T/

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
  2024-12-17 15:32 Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application") Thomas De Schampheleire
@ 2024-12-17 15:53 ` Greg KH
  2024-12-18 12:28   ` Thomas De Schampheleire
  0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2024-12-17 15:53 UTC (permalink / raw)
  To: Thomas De Schampheleire; +Cc: stable, Borislav Petkov (AMD)

On Tue, Dec 17, 2024 at 04:32:55PM +0100, Thomas De Schampheleire wrote:
> Hello,
> 
> Below commit was ported to 6.12, but I would like to request porting to the 6.6
> longterm branch we are currently using:
> 
>     commit c809b0d0e52d01c30066367b2952c4c4186b1047
>     Author: Borislav Petkov (AMD) <bp@alien8.de>
>     Date:   2024-11-19 12:21:33 +0100
> 
>         x86/microcode/AMD: Flush patch buffer mapping after application
>         [...]
> 
> 
> The patch itself is small, but the consequence of not patching is large on
> affected systems (tens of seconds to minutes, of boot delay). See original
> discussion [1] for details.
> 
> The patch in master relies on a variable 'bsp_cpuid_1_eax' introduced in commit
> 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the
> patch ID"), but porting that entire commit seems excessive, especially because
> there are several 'Fixes' commits for that one (e.g. 5343558a868e, d1744a4c975b,
> 1d81d85d1a19).
> 
> I think the simplest prerequisite change is (for Borislav Petkov to confirm):

Please send a set of working, and tested, commits that you wish for us
to commit, we can't cherry-pick stuff out of an email like this for
obvious reasons :)

And whenever possible, yes, we do want to take the fixes that are in
Linus's tree, otherwise maintaining the branch over time gets harder and
harder.  So just backport them all please.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
  2024-12-17 15:53 ` Greg KH
@ 2024-12-18 12:28   ` Thomas De Schampheleire
  2024-12-23 12:33     ` Greg KH
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2024-12-18 12:28 UTC (permalink / raw)
  To: Greg KH, Borislav Petkov (AMD); +Cc: stable

On Tue, Dec 17, 2024 at 04:53:43PM +0100, Greg KH wrote:
> 
> Please send a set of working, and tested, commits that you wish for us
> to commit, we can't cherry-pick stuff out of an email like this for
> obvious reasons :)
> 
> And whenever possible, yes, we do want to take the fixes that are in
> Linus's tree, otherwise maintaining the branch over time gets harder and
> harder.  So just backport them all please.

Thanks Greg for your input, understood.

Borislav, are you open to preparing the required commits?
While I can test the behavior of the main patch, I don't know enough about the
prerequisite patches to handle patch submission.

Thanks,
Thomas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
  2024-12-18 12:28   ` Thomas De Schampheleire
@ 2024-12-23 12:33     ` Greg KH
  2024-12-23 13:23       ` Thomas De Schampheleire
  0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2024-12-23 12:33 UTC (permalink / raw)
  To: Thomas De Schampheleire; +Cc: Borislav Petkov (AMD), stable

On Wed, Dec 18, 2024 at 01:28:55PM +0100, Thomas De Schampheleire wrote:
> On Tue, Dec 17, 2024 at 04:53:43PM +0100, Greg KH wrote:
> > 
> > Please send a set of working, and tested, commits that you wish for us
> > to commit, we can't cherry-pick stuff out of an email like this for
> > obvious reasons :)
> > 
> > And whenever possible, yes, we do want to take the fixes that are in
> > Linus's tree, otherwise maintaining the branch over time gets harder and
> > harder.  So just backport them all please.
> 
> Thanks Greg for your input, understood.
> 
> Borislav, are you open to preparing the required commits?

Wait, why do you want these for the 6.6.y tree if you haven't even
tested to see if they are required or work there?  Why not just move to
6.12.y instead as you know that works.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
  2024-12-23 12:33     ` Greg KH
@ 2024-12-23 13:23       ` Thomas De Schampheleire
  2024-12-23 15:49         ` Greg KH
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2024-12-23 13:23 UTC (permalink / raw)
  To: Greg KH; +Cc: Borislav Petkov (AMD), stable

On Mon, Dec 23, 2024 at 01:33:17PM +0100, Greg KH wrote:
> Wait, why do you want these for the 6.6.y tree if you haven't even
> tested to see if they are required or work there?  Why not just move to
> 6.12.y instead as you know that works.

The original problem was reported by me on 6.6.y.
I tested the patch provided by Borislav on 6.6.y. As mentioned, a small change
is required to make it compile, but this is a nonfunctional change in the
tested code path and so didn't influence test results.
I can therefore say with certainty that the fix is required on 6.6.y .

In these discussions, I requested Borislav if the patch could also be submitted
for 6.6.y, and made him aware that variable 'bsp_cpuid_1_eax' used in the patch
does not yet exist in that branch. He replied [1]:

    "That's fine - stable folks usually know what to pick up. If not, I'll
    provide backports."


I cannot currently move to 6.12 for these systems, this has other consequences
and testing efforts.

Thanks,
Thomas

[1] https://lore.kernel.org/lkml/20241119111728.GAZzxzyHj8U99cEHQ8@fat_crate.local/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
  2024-12-23 13:23       ` Thomas De Schampheleire
@ 2024-12-23 15:49         ` Greg KH
  0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2024-12-23 15:49 UTC (permalink / raw)
  To: Thomas De Schampheleire; +Cc: Borislav Petkov (AMD), stable

On Mon, Dec 23, 2024 at 02:23:48PM +0100, Thomas De Schampheleire wrote:
> I cannot currently move to 6.12 for these systems, this has other consequences
> and testing efforts.

Why?  Your testing efforts should be identical for a stable kernel
update or a movement to a new kernel version.  What is not working
properly for you in 6.12.y?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-12-23 15:49 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-17 15:32 Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application") Thomas De Schampheleire
2024-12-17 15:53 ` Greg KH
2024-12-18 12:28   ` Thomas De Schampheleire
2024-12-23 12:33     ` Greg KH
2024-12-23 13:23       ` Thomas De Schampheleire
2024-12-23 15:49         ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox