summaryrefslogtreecommitdiff
path: root/mm/cma.h
diff options
context:
space:
mode:
authorBorislav Petkov <bp@suse.de>2018-03-14 19:36:15 +0100
committerThomas Gleixner <tglx@linutronix.de>2018-03-16 20:55:51 +0100
commitbb8c13d61a629276a162c1d2b1a20a815cbcfbb7 (patch)
treea222394a2e4e3b3b8346df9c1713d0fb17e56bf3 /mm/cma.h
parent2613f36ed965d0e5a595a1d931fd3b480e82d6fd (diff)
x86/microcode: Fix CPU synchronization routine
Emanuel reported an issue with a hang during microcode update because my dumb idea to use one atomic synchronization variable for both rendezvous - before and after update - was simply bollocks: microcode: microcode_reload_late: late_cpus: 4 microcode: __reload_late: cpu 2 entered microcode: __reload_late: cpu 1 entered microcode: __reload_late: cpu 3 entered microcode: __reload_late: cpu 0 entered microcode: __reload_late: cpu 1 left microcode: Timeout while waiting for CPUs rendezvous, remaining: 1 CPU1 above would finish, leave and the others will still spin waiting for it to join. So do two synchronization atomics instead, which makes the code a lot more straightforward. Also, since the update is serialized and it also takes quite some time per microcode engine, increase the exit timeout by the number of CPUs on the system. That's ok because the moment all CPUs are done, that timeout will be cut short. Furthermore, panic when some of the CPUs timeout when returning from a microcode update: we can't allow a system with not all cores updated. Also, as an optimization, do not do the exit sync if microcode wasn't updated. Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lkml.kernel.org/r/20180314183615.17629-2-bp@alien8.de
Diffstat (limited to 'mm/cma.h')
0 files changed, 0 insertions, 0 deletions