Re: latest -git: WARNING: at arch/x86/kernel/ipi.c:123 send_IPI_mask_bitmask+0xc3/0xe0()

["H. Peter Anvin" <hpa@zytor.com>]

Andi Kleen wrote:
>> We still need the equivalent functionality, though.  The midlayer 
>> (msr_on_cpu) may be pointless, but that doesn't change the fact that 
>> putting this functionality in the lower layer (smp_call_function_single) 
>> makes more sense.
> 
> Assuming you can actually have interrupts enabled at these point
> and be otherwise ready to do call_function_simple (e.g. cpu hotplug
> locking etc.) 
> 
> For a lot of MSR accesses in more complicated subsystems like cpufreq 
> that requires complications.  I would think for many circumstances it's 
> better to simply set affinity of the thread before at a higher level.
> 
> In hindsight I think it was my mistake to ever merge that.
> I admit I never liked it, but just merged it because I wasn't able
> to come up with a strong enough counter argument back then.

Well, smp_call_function_single already does all necessary locking; it 
makes more sense for it to check that what it's about to call still 
exists while inside the lock, instead of requiring the higher layers to 
guarantee that cannot happen on it.  This is simply a matter of the cost 
of checking at this point being quite low.

	-hpa