Drop microcode cache when load operation fails to update microcode.

Also make __apply_microcode_amd() return correct error.

Boris Ostrovsky (2):
  x86/microcode/AMD: Fix __apply_microcode_amd()'s return value
  x86/microcode/AMD: Clean the cache if update did not load microcode

 arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
2.43.5

* Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

> Drop microcode cache when load operation fails to update microcode.
> 
> Also make __apply_microcode_amd() return correct error.
> 
> Boris Ostrovsky (2):
>   x86/microcode/AMD: Fix __apply_microcode_amd()'s return value
>   x86/microcode/AMD: Clean the cache if update did not load microcode
> 
>  arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Should these be Cc: stable perhaps?

Thanks,

	Ingo

On 3/27/25 5:33 PM, Ingo Molnar wrote:
> * Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>
>> Drop microcode cache when load operation fails to update microcode.
>>
>> Also make __apply_microcode_amd() return correct error.
>>
>> Boris Ostrovsky (2):
>>    x86/microcode/AMD: Fix __apply_microcode_amd()'s return value
>>    x86/microcode/AMD: Clean the cache if update did not load microcode
>>
>>   arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
> Should these be Cc: stable perhaps?


Definitely the first patch. The second one is not really a fix but 
rather an improvement.

Will resend. Thanks.


-boris

* boris.ostrovsky@oracle.com <boris.ostrovsky@oracle.com> wrote:

> 
> On 3/27/25 5:33 PM, Ingo Molnar wrote:
> > * Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> > 
> > > Drop microcode cache when load operation fails to update microcode.
> > > 
> > > Also make __apply_microcode_amd() return correct error.
> > > 
> > > Boris Ostrovsky (2):
> > >    x86/microcode/AMD: Fix __apply_microcode_amd()'s return value
> > >    x86/microcode/AMD: Clean the cache if update did not load microcode
> > > 
> > >   arch/x86/kernel/cpu/microcode/amd.c | 9 ++++++++-
> > >   1 file changed, 8 insertions(+), 1 deletion(-)
> > Should these be Cc: stable perhaps?
> 
> 
> Definitely the first patch. The second one is not really a fix but rather an
> improvement.

Well, #2 seems to be fixing a real bug too:

  If microcode did not get loaded there is no reason to keep it in the cache.
  Moreover, if loading failed it will not be possible to load an earlier
  version of microcode since failed version will always be selected from
  the cache on next reload attempt.

this bug basically regresses the ability to load an earlier version of 
the microcode, if a newer version's loading has failed.

It would be a pretty common usecase to attempt to load the earlier 
version if the loading of a new one doesn't succeed, right?

Thanks,

	Ingo

On Fri, Mar 28, 2025 at 02:36:14PM +0100, Ingo Molnar wrote:
> It would be a pretty common usecase to attempt to load the earlier 
> version if the loading of a new one doesn't succeed, right?

This is only for late loading and no one should do that anyway.

And load failure almost never happens - unless you're a cloud guy doing
special hackery.

So no need to expedite this as a fix - the majority does not care.

Thx.

-- 
Regards/Gruss,
    Boris.

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

* Borislav Petkov <bp@alien8.de> wrote:

> On Fri, Mar 28, 2025 at 02:36:14PM +0100, Ingo Molnar wrote:
> > It would be a pretty common usecase to attempt to load the earlier 
> > version if the loading of a new one doesn't succeed, right?
> 
> This is only for late loading and no one should do that anyway.
> 
> And load failure almost never happens - unless you're a cloud guy doing
> special hackery.
> 
> So no need to expedite this as a fix - the majority does not care.

Well, it's a regression over previous behavior, so it is a regression 
fix for an upstream change that is only a few weeks old, and it's an 
overall quality-of-life fix for those users that are affected. There's 
no exception to the expected upstreaming of regression fixes just 
because there's few users affected.

Given how simple the fix looks, and how fresh the recent big microcode 
loading changes are to begin with, I think we should apply it to 
x86/urgent and then (maybe) it can be forwarded to -stable in a few 
weeks if there's no problems. (Or not.)

Ie. my main point is that delaying it to v6.16 is not justified IMHO.

Thanks,

	Ingo

On Fri, Mar 28, 2025 at 02:53:06PM +0100, Ingo Molnar wrote:
> Well, it's a regression over previous behavior,

It is not a regression from a previous behavior because this has always been
this way.

> so it is a regression fix for an upstream change that is only a few weeks
> old,

The late loading is not a few weeks old.

Sounds like you're confused. Find me on IRC and we can discuss it.

Thx.

-- 
Regards/Gruss,
    Boris.

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

On Thu, Mar 27, 2025 at 05:44:32PM -0400, boris.ostrovsky@oracle.com wrote:
> Will resend.

No need to resend - I'll sort it out.

Thx.

-- 
Regards/Gruss,
    Boris.

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