Messages in this thread | | | Date | Mon, 21 Sep 2009 12:04:50 +0800 | From | Xiao Guangrong <> | Subject | Re: + generic-ipi-fix-the-race-between-generic_smp_call_function_-and-hotplug_cfd.patch added to -mm tree |
| |
Suresh Siddha wrote: > On Sun, 2009-09-20 at 19:55 -0700, Xiao Guangrong wrote: >> Suresh Siddha wrote: >>> On Wed, 2009-09-16 at 20:00 -0700, Xiao Guangrong wrote: >>>> How about manual check/handle pending IPI interruption in the CPU context? >>>> like this: >>>> --- a/kernel/cpu.c >>>> +++ b/kernel/cpu.c >>>> @@ -173,6 +173,9 @@ static int __ref take_cpu_down(void *_param) >>>> struct take_cpu_down_param *param = _param; >>>> int err; >>>> >>>> + generic_smp_call_function_interrupt(); >>>> + generic_smp_call_function_single_interrupt(); >>>> + >>> At this place, how will you ensure that the smp_call_function initiated >>> by this dying cpu has reached and got serviced at its destination? >>> >> Suresh, sorry for my poor English, Do you mean that how we ensure it has >> pending IPI request in the dying cpu? >> >> generic_smp_call_function_*() will check it, if the cpu has pending request, >> then handle it, else directly return. >> > > I am referring to the missing csd_lock_wait() here that you had in the > first version of your patch. Let's say, if cpu X is going offline, we > need to ensure that the smp_call_function() initiated by cpu X (i.e., > smp_call_function IPI sent to some other cpu's from cpu X) got serviced > before cpu X goes offline. We can't do csd_lock_wait() here, as that > might deadlock (as all the other cpu's are already in stop machine with > interrupts disabled). >
It not happen because the preemption is disabled while send IPI request and can't schedule to stop machine path, it also stop cpu down.
Thanks, Xiao
| |