lkml.org 
[lkml]   [2023]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patch V2 09/37] x86/microcode/intel: Remove pointless mutex
From


On 12.08.23 г. 22:58 ч., Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> There is no concurreny.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> ---
> arch/x86/kernel/cpu/microcode/intel.c | 24 ++----------------------
> 1 file changed, 2 insertions(+), 22 deletions(-)
> ---
> --- a/arch/x86/kernel/cpu/microcode/intel.c
> +++ b/arch/x86/kernel/cpu/microcode/intel.c
> @@ -397,22 +397,6 @@ scan_microcode(void *data, size_t size,
> return patch;
> }
>
> -/*
> - * Save this microcode patch. It will be loaded early when a CPU is
> - * hot-added or resumes.
> - */
> -static void save_mc_for_early(struct ucode_cpu_info *uci, u8 *mc, unsigned int size)
> -{
> - /* Synchronization during CPU hotplug. */
> - static DEFINE_MUTEX(x86_cpu_microcode_mutex);
> -
> - mutex_lock(&x86_cpu_microcode_mutex);
> -
> - save_microcode_patch(uci, mc, size);
> -
> - mutex_unlock(&x86_cpu_microcode_mutex);
> -}
> -


So this function is ultimately invoked from a write to the 'reload'
sysfs file, what about 2 racing writes to this file ? Though if it's
about cpu hotplug then in reload_store() this is handled via
cpus_read_lock I guess so indeed this is correct.

\
 
 \ /
  Last update: 2023-08-13 08:56    [W:4.021 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site