2012/11/29 Gleb Natapov <gleb@xxxxxxxxxx>:
> On Wed, Nov 28, 2012 at 03:25:07PM +0100, Frederic Weisbecker wrote:
>> 2012/11/28 Gleb Natapov <gleb@xxxxxxxxxx>:
>> > On Wed, Nov 28, 2012 at 01:55:42PM +0100, Frederic Weisbecker wrote:
>> >> Yes but if rcu_irq_*() calls are fine to be called there, and I
>> >> believe they are because exception_enter() exits the user mode, we
>> >> should start to protect there right now instead of waiting for a
>> >> potential future warning of illegal RCU use.
>> >>
>> > Async page not present is not much different from regular page fault
>> > exception when it happens not on idle task (regular #PF cannot happen
>> > on idle task), but code have a special handling for idle task. So why
>> > do you think rcu_irq_*() is required here, but not in page fault
>> > handler?
>>
>> Because we are not supposed to fault in idle, at least I hope there
>> are no case around. Except on cases like here with KVM I guess but we
>> have that special async handler for that.
>>
> As far as I understand rcu_irq_enter() should be called before entering
> the mode in which read-side critical sections can occur, but async page
> fault does not uses RCU in case of faulting in idle. Actually, looking
> closer, it may call kfree() if page ready notification arrives ahead
> of not present notification (with todays KVM it cannot happen) and we
> have to assume that kfree() uses rcu read even if it currently does not.
> So may be it is possible to move rcu_irq_*() calls to be around unlikely
> kfree() call only.
Please, let's protect kvm_async_pf_task_wait() entirely. This is less
complicated and we don't need to audit the code and its evolution. And
that is a complicated code enough already. We just need to do:
exception_enter();
rcu_irq_enter()
kvm_async_pf_task_wait() {
rcu_irq_exit();
native_safe_halt();
rcu_irq_enter();
}
rcu_irq_exit()
exception_exit();
To me it looks like the safest and simplest solution.
rcu_irq_exit()
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
