Viresh,
On 2015/1/30 10:05, Viresh Kumar wrote:
On 30 January 2015 at 07:00, ethan zhao <ethan.zhao@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html