lkml.org 
[lkml]   [2012]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kvm: fix race with level interrupts
    On Wed, Jul 18, 2012 at 05:20:40PM -0600, Alex Williamson wrote:
    > On Thu, 2012-07-19 at 01:49 +0300, Michael S. Tsirkin wrote:
    > > On Wed, Jul 18, 2012 at 04:26:41PM -0600, Alex Williamson wrote:
    > > > On Thu, 2012-07-19 at 00:52 +0300, Michael S. Tsirkin wrote:
    > > > > When more than 1 source id is in use for the same GSI, we have the
    > > > > following race related to handling irq_states:
    > > > >
    > > > > CPU 0 clears bit in irq_states. CPU 0 reads irq_state as 0.
    > > > > CPU 1 sets bit in irq_states. CPU 1 calls kvm_ioapic_set_irq(1). CPU 0
    > > > > calls kvm_ioapic_set_irq(0).
    > > > >
    > > > > Now ioapic thinks the level is 0 but irq_state is not 0.
    > > > >
    > > > > Note that above is valid behaviour if CPU0 and CPU1 are using different
    > > > > source ids.
    > > > >
    > > > > Fix by performing all irq_states bitmap handling under pic/ioapic lock.
    > > > > This also removes the need for atomics with irq_states handling.
    > > > >
    > > > > Reported-by: Gleb Natapov <gleb@redhat.com>
    > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    > > > > ---
    > > > >
    > > > > This survives stress testing for me (though I only tried virtio, not
    > > > > device assignment).
    > > > > Avi, Marcelo, though we have not observed this in the field,
    > > > > it's a bugfix so probably 3.5 material?
    > > > > I assume yes so the patch is against 3.5-rc7.
    > > > > Also stable? It's a very old bug.
    > > > >
    > > > >
    > > > > arch/x86/include/asm/kvm_host.h | 15 ++++++++++++++-
    > > > > arch/x86/kvm/i8259.c | 14 ++++++++++++--
    > > > > virt/kvm/ioapic.c | 13 ++++++++++++-
    > > > > virt/kvm/ioapic.h | 4 +++-
    > > > > virt/kvm/irq_comm.c | 31 ++++---------------------------
    > > > > 5 files changed, 45 insertions(+), 32 deletions(-)
    > > > >
    > > > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
    > > > > index db7c1f2..fe6e9f1 100644
    > > > > --- a/arch/x86/include/asm/kvm_host.h
    > > > > +++ b/arch/x86/include/asm/kvm_host.h
    > > > > @@ -802,7 +802,20 @@ int kvm_read_guest_page_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
    > > > > void kvm_propagate_fault(struct kvm_vcpu *vcpu, struct x86_exception *fault);
    > > > > bool kvm_require_cpl(struct kvm_vcpu *vcpu, int required_cpl);
    > > > >
    > > > > -int kvm_pic_set_irq(void *opaque, int irq, int level);
    > > > > +static inline int kvm_irq_line_state(unsigned long *irq_state,
    > > > > + int irq_source_id, int level)
    > > >
    > > > This should probably be __kvm_irq_line_state given the calling
    > > > restrictions.
    > >
    > > It's such a trivial helper, do we need to split hairs about this?
    > >
    > > Look it's not a good time for minor coding style nits.
    > > 3.5 is imminent, it's about 1am here and I really don't have time to retest
    > > today, so we'll release another kernel with a bug.
    > >
    > > Could you focus on reviewing the functionality and correctness, and
    > > leave ideas for better variable naming aside until 3.6?
    >
    > Please get off your high horse, this bug has existed for a long time and
    > nobody has noticed. __ indicates locking and makes people think twice
    > about arbitrarily calling it. Correct naming prevents future bugs,
    > which is something you've been riding me on in other areas...
    >
    Agree, this is not a recent regression and in fact the bug cannot be
    triggered without device assignment that uses level interrupt (is this
    works at all?).

    --
    Gleb.


    \
     
     \ /
      Last update: 2012-07-19 10:21    [W:0.027 / U:32.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site