linux-toradex.git/virt/kvm/eventfd.c, branch v4.19-rc8

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2018-07-18T18:08:44+00:00

Pull kvm fixes from Paolo Bonzini:
 "Miscellaneous bugfixes, plus a small patchlet related to Spectre v2"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  kvmclock: fix TSC calibration for nested guests
  KVM: VMX: Mark VMXArea with revision_id of physical CPU even when eVMCS enabled
  KVM: irqfd: fix race between EPOLLHUP and irq_bypass_register_consumer
  KVM/Eventfd: Avoid crash when assign and deassign specific eventfd in parallel.
  x86/kvmclock: set pvti_cpu0_va after enabling kvmclock
  x86/kvm/Kconfig: Ensure CRYPTO_DEV_CCP_DD state at minimum matches KVM_AMD
  kvm: nVMX: Restore exit qual for VM-entry failure due to MSR loading
  x86/kvm/vmx: don't read current->thread.{fs,gs}base of legacy tasks
  KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR

KVM: irqfd: fix race between EPOLLHUP and irq_bypass_register_consumer

2018-07-18T09:31:27+00:00

A comment warning against this bug is there, but the code is not doing what
the comment says.  Therefore it is possible that an EPOLLHUP races against
irq_bypass_register_consumer.  The EPOLLHUP handler schedules irqfd_shutdown,
and if that runs soon enough, you get a use-after-free.

Reported-by: syzbot 
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Reviewed-by: David Hildenbrand

KVM/Eventfd: Avoid crash when assign and deassign specific eventfd in parallel.

2018-07-18T09:31:27+00:00

Syzbot reports crashes in kvm_irqfd_assign(), caused by use-after-free
when kvm_irqfd_assign() and kvm_irqfd_deassign() run in parallel
for one specific eventfd. When the assign path hasn't finished but irqfd
has been added to kvm->irqfds.items list, another thead may deassign the
eventfd and free struct kvm_kernel_irqfd(). The assign path then uses
the struct kvm_kernel_irqfd that has been freed by deassign path. To avoid
such issue, keep irqfd under kvm->irq_srcu protection after the irqfd
has been added to kvm->irqfds.items list, and call synchronize_srcu()
in irq_shutdown() to make sure that irqfd has been fully initialized in
the assign path.

Reported-by: Dmitry Vyukov 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Dmitry Vyukov 
Signed-off-by: Tianyu Lan 
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini

fs: add new vfs_poll and file_can_poll helpers

2018-05-26T07:16:44+00:00

These abstract out calls to the poll method in preparation for changes
in how we poll.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong

vfs: do bulk POLL* -> EPOLL* replacement

2018-02-11T22:34:03+00:00

This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.

Scripted-by: Al Viro 
Signed-off-by: Linus Torvalds

annotate poll-related wait keys

2017-11-27T21:19:54+00:00

__poll_t is also used as wait key in some waitqueues.
Verify that wait_..._poll() gets __poll_t as key and
provide a helper for wakeup functions to get back to
that __poll_t value.

Signed-off-by: Al Viro

anntotate the places where ->poll() return values go

2017-11-27T21:19:53+00:00

Signed-off-by: Al Viro

Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"

2017-09-19T06:37:17+00:00

This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563.

The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also,
there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where larger
gsi values make sense.

As the commit was meant as an early indicator to user space that
something is wrong, reverting just restores the previous behavior
where overly large values are ignored when encountered (without
any direct feedback).

Reported-by: Abdul Haleem 
Signed-off-by: Jan H. Schönherr 
Reviewed-by: David Hildenbrand 
Signed-off-by: Radim Krčmář

KVM: Don't accept obviously wrong gsi values via KVM_IRQFD

2017-09-15T14:55:28+00:00

We cannot add routes for gsi values >= KVM_MAX_IRQ_ROUTES -- see
kvm_set_irq_routing(). Hence, there is no sense in accepting them
via KVM_IRQFD. Prevent them from entering the system in the first
place.

Signed-off-by: Jan H. Schönherr 
Signed-off-by: Paolo Bonzini

Merge branch 'annotations' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux into kvm-master

2017-07-10T12:44:24+00:00