lkml.org 
[lkml]   [2009]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/3] work_on_cpu: Use our own workqueue.
On 01/26, Mike Travis wrote:
>
> Ingo Molnar wrote:
> > * Oleg Nesterov <oleg@redhat.com> 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.



\
 
 \ /
  Last update: 2009-01-27 01:15    [W:0.666 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site