Re: [patch 10/11] [PATCH 10/11] x86: Major refactoring.

[Max Krasnyansky]

Peter Oruba wrote:
> Refactored code by introducing a two-module solution. There is one
> general module in which vendor specific modules can hook into.
> However, that is exclusive, there is only one vendor specific module
> allowed at a time. A CPU vendor check makes sure only the corect
> module for the underlying system gets called. Functinally in terms
> of patch loading itself there are no changes. This refactoring
> provides a basis for future implementations of other vendors'
> patch loaders.
>
> Signed-off-by: Peter Oruba <peter.oruba@xxxxxxx>
<snip>

> diff --git a/arch/x86/kernel/microcode.c b/arch/x86/kernel/microcode.c
> index c1047d7..1e42e79 100644
> --- a/arch/x86/kernel/microcode.c
> +++ b/arch/x86/kernel/microcode.c
<snip>

> @@ -244,9 +243,9 @@ static void microcode_init_cpu(int cpu, int resume)
>  
>  	set_cpus_allowed_ptr(current, newmask);
>  	mutex_lock(&microcode_mutex);
> -	collect_cpu_info(cpu);
> +	microcode_ops->collect_cpu_info(cpu);
>  	if (uci->valid && system_state == SYSTEM_RUNNING && !resume)
> -		cpu_request_microcode(cpu);
> +		microcode_ops->cpu_request_microcode(cpu);
>  	mutex_unlock(&microcode_mutex);
>  	set_cpus_allowed_ptr(current, &old);
> @@ -274,7 +273,7 @@ static ssize_t reload_store(struct sys_device *dev,
>  
>  		mutex_lock(&microcode_mutex);
>  		if (uci->valid)
> -			err = cpu_request_microcode(cpu);
> +			err = microcode_ops->cpu_request_microcode(cpu);
>  		mutex_unlock(&microcode_mutex);
>  		put_online_cpus();
>  		set_cpus_allowed_ptr(current, &old);

Peter, question while we're at it. This came up in another thread and I 
asked the same question to Tigran but he is either on vacation or not 
paying attention :).

Microcode cpu hotplug handler is messing with the cps_allowed flags of a 
random process and can race with sched_setaffinity() (pointed by 
Dmitry). It also makes some assumptions on the overall cpu hotplug 
sequence which is bad.

It's easy to fix but the question is - does the microcode update need to 
happen synchronously ? I'm thinking that it does not but I wanted to 
verify that. If it does not need to be synchronous then we can simply 
schedule a work queue and do the update there. If it does we could do 
collect_cpu_info() and load_microcode() in the IPIs.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/