Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries

[Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>]

* Darren Hart <dvhltc@us.ibm.com> [2010-08-04 21:45:51]:

> On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote:
> >* Benjamin Herrenschmidt<benh@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.
> 
> Hi Vaidy, have you been able to dig anything up about the
> decrementer expiry?

Hi Darren,

Yes, it is possible that the cpu in extended_cede_processor() can be
woken up by the decrementer.  But the expectation is that we will
return back to this context since we will not have any pending timers.

Our stack should not change even if we get the decrementer interrupts.

--Vaidy