linux-kernel - Re: [patch V2 09/37] x86/microcode/intel: Remove pointless mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1fb4972-765a-d06a-14d1-028a8a75bd97@suse.com>
Date:   Sun, 13 Aug 2023 09:55:06 +0300
From:   Nikolay Borisov <nik.borisov@...e.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, Borislav Petkov <bp@...en8.de>,
        Ashok Raj <ashok.raj@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [patch V2 09/37] x86/microcode/intel: Remove pointless mutex



On 12.08.23 г. 22:58 ч., Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
> 
> There is no concurreny.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.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.