[PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
svaidy at linux.vnet.ibm.com
Fri Jul 23 17:07:01 EST 2010
* Benjamin Herrenschmidt <benh at kernel.crashing.org> [2010-07-23 15:11:00]:
> On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:
> > Yes. extended_cede_processor() will return with interrupts enabled in
> > the cpu. (This is done by the hypervisor). Under normal cases we
> > cannot be interrupted because no IO interrupts are routed to us after
> > xics_teardown_cpu() and since the CPU is out of the map, nobody will
> > send us IPIs.
> What about decrementer ?
Decrementer expiry event handling is bit complex. The event as such
may not bring back the extended_cede_processor() cpu, but may be
marked pending when we get out of this state eventually. I will find
more information on this event and update.
> > Though H_CEDE will return with interrupts enabled, it is unlikely that
> > an interrupt can be delivered in this context.
> Well, if interrupts are soft-disabled, even if one occurs, we will just
> mask and return, so that at least should be ok.
Yes. We will immediately return to the extended_cede_processor() in
the while loop until the preferred_offline_state is changed.
More information about the Linuxppc-dev