Re: [PATCH] x86/microcode/intel: Panic on partial microcode update

[Maciej W. Rozycki]

On Tue, 30 Jun 2026, Dave Hansen wrote:

> Thinking about this a bit more: I don't think we should panic. It's
> perfectly fine to spew a nice scary warning. But we really should
> continue unless we really *know* that something has gone so horribly
> wrong that it's dangerous to continue.

 Is there no risk for silent data corruption such as in storage after a 
broken ucode update?

> Think about things like folks who are ssh'd in. Say they have a bad,
> partial ucode update. With this approach, they get a dead ssh session.
> 
> If you WARN() and keep going, they at least have a chance of seeing the
> spew and getting it off the system.

 A panic() message may not make it there, but KERN_EMERG messages ought to 
make it to all the terminal sessions via syslogd(8) where logging has been 
correctly configured for a system (so up to the local policy to get it 
right).  A way to force it through could be needed here though.

 Then there's the system console the kernel messages are usually produced 
to (again, subject to the local policy) one could watch; one might argue 
even that such a dangerous operation on a live system would best be done 
via the console terminal (even if it means IPMI nowadays).

> I mean, the ucode update guys themselves could definitely have reset the
> system if it needed to. They also know when it is dangerous to keep the
> CPU running. They obviously don't think that this partial update thing
> is *THAT* dangerous or they wouldn't have even let the CPU keep
> churning. Right?

 Umm, what the reasonable alternative would be for the RTL designer, a CPU 
shutdown?  Then you'd have no good way to figure out what really happened.

  Maciej