Re: [PATCH] cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

ethan zhao
2015-01-30T02:10:38Z

Viresh,

On 2015/1/30 10:05, Viresh Kumar wrote:
> On 30 January 2015 at 07:00, ethan zhao <ethan.zhao@oracle.com> wrote:
>
>> It is another bug.
> Hmm, lets see..
>
>> Yes, here is one bug should be fix. but seems not enough to avoid the issue
>> completely,
> Did you test it ?
For a PPC notification and xen-bus thread race, could you tell me a way how
to reproduce it by trigger the PPC notification and xen-bus events
manually ?
You really want me write some code into a test kernel to flood the PPC
and xen-bus at the same time ? if we could analysis code and get the
issue clearly,
we wouldn't wait the users to yell out.

Thanks,
Ethan

>
>> how about the Thread B running here
>>
>> Thread B: xenbus_thread()
>>
>> xenbus_thread()
>> msg->u.watch.handle->callback()
>> handle_vcpu_hotplug_event()
>> vcpu_hotplug()
>> cpu_down()
>> __cpu_notify(CPU_POST_DEAD..)
>> cpufreq_cpu_callback()
>> __cpufreq_remove_dev_prepare
>> update_policy_cpu(){
>> ...
>> down_write(&policy->rwsem);
>> policy->last_cpu = policy->cpu;
>> policy->cpu = cpu;
>> up_write(&policy->rwsem);
>> ---->
>> }
>>
>> And thread A run to the same position as above, don't ignore my work
>> blindly, that piece of bandage
>> could save your time
> Oh, please don't misunderstand me. I didn't had any intention of showing
> any kind of disrespect.
>
> Okay, why do you say that the above thread you shown has a bug in there?
> Its juse updating policy->cpu and that shouldn't make anything unstable.
>
> Please explain again one more time, in details why do you think you hit a
> different bug. Also look at kref.h to see which piece of code has hit that
> WARN() and it will happen only in the case I have shown. Lets see if I
> missed something :)
>
> --
> viresh