Re: [Xen-devel] [PATCH v2] Fix scheduler crash after s3 resume

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.01.13 at 10:45, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:

>> I think I had already raised the question of the placement of
>> this rcu_barrier() here, and the lack of a counterpart in the
>> suspend portion of the path. Keir? Or should
>> rcu_barrier_action() avoid calling process_pending_softirqs()
>> while still resuming, and instead call __do_softirq() with all but
>> RCU_SOFTIRQ masked (perhaps through a suitable wrapper,
>> or alternatively by open-coding its effect)?
>>
> Though I recall these vcpu_wake crashes happen also from other entry 
> points in enter_state but rcu_barrier, so I dont think removing that 
> helps much. Just was unable to get a proper log of them today due to 
> most of them being cut in half. Will try bit more.

In which case making __do_softirq() itself honor being in the
suspend/resume path might still be an option.

> My belief is that as long as vcpu_migrate is not called in 
> cpu_disable_scheduler, the vcpu->processor shall continue to point to 
> offline cpu. Which will crash if the vcpu_wake is called for that vcpu. 
> If vcpu_migrate is called, then vcpu_wake will still be called with some 
> frequency but since vcpu->processor shall point to online cpu, and it 
> won't crash. So likely avoiding the wakes here completely is not the 
> goal, just the offline ones.

But you neglect the fact that waking vCPU-s at this point is
unnecessary anyway (they have nowhere to run on).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel