On 01/26, Mike Travis wrote: > > Ingo Molnar wrote: > > * Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > >> But "[PATCH 1/3] work_on_cpu: dont try to get_online_cpus() in > >> work_on_cpu." removes get_online_cpus/put_online_cpus, this means the > >> work can run on the wrong CPU anyway. Or work_on_cpu() can hang forever > >> if CPU has already gone away before queue_work_on(). > >> > >> Confused. > > > > The idea was to require work_on_cpu() users to be CPU hotplug-safe. But > > ... Rusty pointed it out in the past that this might be fragile, and we > > could put back the get_online_cpus()/put_online_cpus() calls. > > > > Rusty, what do you think? > > > > Ingo > > > I believe that is the intention, in that the caller should insure that > the cpu does not go offline. But also as Rusty stated, the previous usages > of set_cpus_allowed did not always insure this, so it's at least not a > regression. Not sure I understand. arch/x86/kernel/cpu/mcheck/mce_amd_64.c:store_interrupt_enable() can race with cpu_down(), but at worst work_on_cpu() returns -EINVAL. However, after the 1/3 patch we can hang forever. Yes, afaics the code was not correct before it was converted to use work_on_cpu(). But now it becomes wrong again? Oleg. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
