The risk would still be present since fire_user_return_notifiers could
potentially run at any time and kvm_on_user return could be called
from drop_user_return_notifiers either from the kvm_put_kvm path or
the kvm_arch_exit path.
Regards
On Wed, Nov 2, 2016 at 10:25 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
>
> On 22/10/2016 00:08, Ignacio Alvarado wrote:
>> Function user_notifier_unregister should be called only once for each
>> registered user notifier.
>>
>> Function kvm_arch_hardware_disable can be executed from an IPI context
>> which could cause a race condition with a VCPU returning to user mode
>> and attempting to unregister the notifier.
>>
>> Signed-off-by: Ignacio Alvarado <ikalvarado@xxxxxxxxxx>
>
> Should drop_user_return_notifiers instead be moved to kvm_arch_exit?
>
> Thanks,
>
> Paolo
>
>> ---
>> arch/x86/kvm/x86.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index e375235..51f87f0 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -210,7 +210,15 @@ static void kvm_on_user_return(struct user_return_notifier *urn)
>> struct kvm_shared_msrs *locals
>> = container_of(urn, struct kvm_shared_msrs, urn);
>> struct kvm_shared_msr_values *values;
>> + unsigned long flags;
>>
>> + /*
>> + * Disabling irqs at this point since the following code could be
>> + * interrupted and executed through kvm_arch_hardware_disable()
>> + */
>> + local_irq_save(flags);
>> + if (!locals->registered)
>> + goto out;
>> for (slot = 0; slot < shared_msrs_global.nr; ++slot) {
>> values = &locals->values[slot];
>> if (values->host != values->curr) {
>> @@ -220,6 +228,8 @@ static void kvm_on_user_return(struct user_return_notifier *urn)
>> }
>> locals->registered = false;
>> user_return_notifier_unregister(urn);
>> +out:
>> + local_irq_restore(flags);
>> }
>>
>> static void shared_msr_update(unsigned slot, u32 msr)
>>
--
Ignacio Alvarado
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
