lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 16 Mar 2020 09:33:50 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linmiaohe@...wei.com, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: X86: correct meaningless kvm_apicv_activated() check

Paolo Bonzini <pbonzini@...hat.com> writes:

> After test_and_set_bit() for kvm->arch.apicv_inhibit_reasons, we will
> always get false when calling kvm_apicv_activated() because it's sure
> apicv_inhibit_reasons do not equal to 0.
>
> What the code wants to do, is check whether APICv was *already* active
> and if so skip the costly request; we can do this using cmpxchg.
>
> Reported-by: Miaohe Lin <linmiaohe@...wei.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/x86.c | 25 ++++++++++++++++---------
>  1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a7cb85231330..49efa4529662 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8049,19 +8049,26 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
>   */
>  void kvm_request_apicv_update(struct kvm *kvm, bool activate, ulong bit)
>  {
> +	unsigned long old, new, expected;
> +
>  	if (!kvm_x86_ops->check_apicv_inhibit_reasons ||
>  	    !kvm_x86_ops->check_apicv_inhibit_reasons(bit))
>  		return;
>  
> -	if (activate) {
> -		if (!test_and_clear_bit(bit, &kvm->arch.apicv_inhibit_reasons) ||
> -		    !kvm_apicv_activated(kvm))
> -			return;
> -	} else {
> -		if (test_and_set_bit(bit, &kvm->arch.apicv_inhibit_reasons) ||
> -		    kvm_apicv_activated(kvm))
> -			return;
> -	}
> +	old = READ_ONCE(kvm->arch.apicv_inhibit_reasons);
> +	do {
> +		expected = new = old;
> +		if (activate)
> +			__clear_bit(bit, &new);
> +		else
> +			__set_bit(bit, &new);
> +		if (new == old)
> +			break;
> +		old = cmpxchg(&kvm->arch.apicv_inhibit_reasons, expected, new);
> +	} while (old != expected);

'expected' here is a bit confusing as it's not what we expect to get as
the result but rather what we expect to see pre-change. I don't have a
better suggestion though.

> +
> +	if ((old == 0) == (new == 0))
> +		return;

This is a very laconic expression I personally find hard to read :-)

	/* Check if WE actually changed APICv state */
        if ((!old && !new) || (old && new))
		return;

would be my preference (not strong though, I read yours several times
and now I feel like I understand it just fine :-)

>  
>  	trace_kvm_apicv_update_request(activate, bit);
>  	if (kvm_x86_ops->pre_update_apicv_exec_ctrl)

Reviewed-by: Vitaly Kuznetsov <vkuznets@...hat.com>

-- 
Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ