linux-kernel - Re: [PATCH v3 5/5] KVM: X86: Fix callers of kvm_apic_match

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191203162747.GD17275@xz-x1>
Date:   Tue, 3 Dec 2019 11:27:47 -0500
From:   Peter Xu <peterx@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     kvm@...r.kernel.org, Nitesh Narayan Lal <nitesh@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/5] KVM: X86: Fix callers of kvm_apic_match_dest() to
 use correct macros

On Tue, Dec 03, 2019 at 02:23:47PM +0100, Vitaly Kuznetsov wrote:
> Peter Xu <peterx@...hat.com> writes:
> 
> > Callers of kvm_apic_match_dest() should always pass in APIC_DEST_*
> > macros for either dest_mode and short_hand parameters.  Fix up all the
> > callers of kvm_apic_match_dest() that are not following the rule.
> >
> > Reported-by: Sean Christopherson <sean.j.christopherson@...el.com>
> > Reported-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> > Signed-off-by: Peter Xu <peterx@...hat.com>
> > ---
> >  arch/x86/kvm/ioapic.c   | 11 +++++++----
> >  arch/x86/kvm/irq_comm.c |  3 ++-
> >  2 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> > index 901d85237d1c..1082ca8d11e5 100644
> > --- a/arch/x86/kvm/ioapic.c
> > +++ b/arch/x86/kvm/ioapic.c
> > @@ -108,8 +108,9 @@ static void __rtc_irq_eoi_tracking_restore_one(struct kvm_vcpu *vcpu)
> >  	union kvm_ioapic_redirect_entry *e;
> >  
> >  	e = &ioapic->redirtbl[RTC_GSI];
> > -	if (!kvm_apic_match_dest(vcpu, NULL, 0,	e->fields.dest_id,
> > -				e->fields.dest_mode))
> > +	if (!kvm_apic_match_dest(vcpu, NULL, APIC_DEST_NOSHORT,
> > +				 e->fields.dest_id,
> > +				 kvm_lapic_irq_dest_mode(e->fields.dest_mode)))
> >  		return;
> >  
> >  	new_val = kvm_apic_pending_eoi(vcpu, e->fields.vector);
> > @@ -237,6 +238,7 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, ulong *ioapic_handled_vectors)
> >  	struct dest_map *dest_map = &ioapic->rtc_status.dest_map;
> >  	union kvm_ioapic_redirect_entry *e;
> >  	int index;
> > +	u16 dm;
> >  
> >  	spin_lock(&ioapic->lock);
> >  
> > @@ -250,8 +252,9 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, ulong *ioapic_handled_vectors)
> >  		if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG ||
> >  		    kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index) ||
> >  		    index == RTC_GSI) {
> > -			if (kvm_apic_match_dest(vcpu, NULL, 0,
> > -			             e->fields.dest_id, e->fields.dest_mode) ||
> > +			dm = kvm_lapic_irq_dest_mode(e->fields.dest_mode);
> 
> Nit: you could've defined 'dm' right here in the block (after '{') but
> in any case I'd suggest to stick to 'dest_mode' and not shorten it to
> 'dm' for consistency.
> 
> > +			if (kvm_apic_match_dest(vcpu, NULL, APIC_DEST_NOSHORT,
> > +						e->fields.dest_id, dm) ||
> >  			    kvm_apic_pending_eoi(vcpu, e->fields.vector))
> >  				__set_bit(e->fields.vector,
> >  					  ioapic_handled_vectors);
> > diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> > index 5f59e5ebdbed..e89c2160b39f 100644
> > --- a/arch/x86/kvm/irq_comm.c
> > +++ b/arch/x86/kvm/irq_comm.c
> > @@ -417,7 +417,8 @@ void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu,
> >  
> >  			kvm_set_msi_irq(vcpu->kvm, entry, &irq);
> >  
> > -			if (irq.level && kvm_apic_match_dest(vcpu, NULL, 0,
> > +			if (irq.level &&
> > +			    kvm_apic_match_dest(vcpu, NULL, APIC_DEST_NOSHORT,
> >  						irq.dest_id, irq.dest_mode))
> >  				__set_bit(irq.vector, ioapic_handled_vectors);
> >  		}
> 
> Reviewed-by: Vitaly Kuznetsov <vkuznets@...hat.com>

I'll move the declaration in with your r-b.  'dm' is a silly trick of
mine to avoid the 80-char line limit.  Thanks,

-- 
Peter Xu