25 May, 2018

20 commits

  • in case kvm_vgic_map_resources() fails, typically if the vgic
    distributor is not defined, __kvm_vgic_destroy will be called
    several times. Indeed kvm_vgic_map_resources() is called on
    first vcpu run. As a result dist->spis is freeed more than once
    and on the second time it causes a "kernel BUG at mm/slub.c:3912!"

    Set dist->spis to NULL to avoid the crash.

    Fixes: ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement
    vgic_init")

    Signed-off-by: Eric Auger
    Reviewed-by: Marc Zyngier
    Reviewed-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Eric Auger
     
  • The conversion of the FPSIMD context switch trap code to C has added
    some overhead to calling it, due to the need to save registers that
    the procedure call standard defines as caller-saved.

    So, perhaps it is no longer worth invoking this trap handler quite
    so early.

    Instead, we can invoke it from fixup_guest_exit(), with little
    likelihood of increasing the overhead much further.

    As a convenience, this patch gives __hyp_switch_fpsimd() the same
    return semantics fixup_guest_exit(). For now there is no
    possibility of a spurious FPSIMD trap, so the function always
    returns true, but this allows it to be tail-called with a single
    return statement.

    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Christoffer Dall
    Reviewed-by: Alex Bennée
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • The entire tail of fixup_guest_exit() is contained in if statements
    of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
    we can check just once and bail out of the function early, allowing
    the remaining if conditions to be simplified.

    The only awkward case is where *exit_code is changed to
    ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
    interface access: in that case, the GICv3 trap handling code is
    skipped using a goto. This avoids pointlessly evaluating the
    static branch check for the GICv3 case, even though we can't have
    vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
    unless we have a GICv3 and GICv2 on the host: that sounds stupid,
    but I haven't satisfied myself that it can't happen.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Alex Bennée
    Acked-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • In fixup_guest_exit(), there are a couple of cases where after
    checking what the exit code was, we assign it explicitly with the
    value it already had.

    Assuming this is not indicative of a bug, these assignments are not
    needed.

    This patch removes the redundant assignments, and simplifies some
    if-nesting that becomes trivial as a result.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Marc Zyngier
    Acked-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • Now that the host SVE context can be saved on demand from Hyp,
    there is no longer any need to save this state in advance before
    entering the guest.

    This patch removes the relevant call to
    kvm_fpsimd_flush_cpu_state().

    Since the problem that function was intended to solve now no longer
    exists, the function and its dependencies are also deleted.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Christoffer Dall
    Acked-by: Marc Zyngier
    Acked-by: Catalin Marinas
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • This patch adds SVE context saving to the hyp FPSIMD context switch
    path. This means that it is no longer necessary to save the host
    SVE state in advance of entering the guest, when in use.

    In order to avoid adding pointless complexity to the code, VHE is
    assumed if SVE is in use. VHE is an architectural prerequisite for
    SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
    kernels that support both SVE and KVM.

    Historically, software models exist that can expose the
    architecturally invalid configuration of SVE without VHE, so if
    this situation is detected at kvm_init() time then KVM will be
    disabled.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Catalin Marinas
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • In order to make sve_save_state()/sve_load_state() more easily
    reusable and to get rid of a potential branch on context switch
    critical paths, this patch makes sve_pffr() inline and moves it to
    fpsimd.h.

    must be included in fpsimd.h in order to make
    this work, and this creates an #include cycle that is tricky to
    avoid without modifying core code, due to the way the PR_SVE_*()
    prctl helpers are included in the core prctl implementation.

    Instead of breaking the cycle, this patch defers inclusion of
    in until the point where it is
    actually needed: i.e., immediately before the prctl definitions.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Catalin Marinas
    Acked-by: Marc Zyngier
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • sve_pffr(), which is used to derive the base address used for
    low-level SVE save/restore routines, currently takes the relevant
    task_struct as an argument.

    The only accessed fields are actually part of thread_struct, so
    this patch changes the argument type accordingly. This is done in
    preparation for moving this function to a header, where we do not
    want to have to include due to the consequent
    circular #include problems.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Catalin Marinas
    Acked-by: Marc Zyngier
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • Having read_zcr_features() inline in cpufeature.h results in that
    header requiring #includes which make it hard to include
    elsewhere without triggering header inclusion
    cycles.

    This is not a hot-path function and arguably should not be in
    cpufeature.h in the first place, so this patch moves it to
    fpsimd.c, compiled conditionally if CONFIG_ARM64_SVE=y.

    This allows some SVE-related #includes to be dropped from
    cpufeature.h, which will ease future maintenance.

    A couple of missing #includes of are exposed by this
    change under arch/arm64/. This patch adds the missing #includes as
    necessary.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Catalin Marinas
    Acked-by: Marc Zyngier
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • This patch refactors KVM to align the host and guest FPSIMD
    save/restore logic with each other for arm64. This reduces the
    number of redundant save/restore operations that must occur, and
    reduces the common-case IRQ blackout time during guest exit storms
    by saving the host state lazily and optimising away the need to
    restore the host state before returning to the run loop.

    Four hooks are defined in order to enable this:

    * kvm_arch_vcpu_run_map_fp():
    Called on PID change to map necessary bits of current to Hyp.

    * kvm_arch_vcpu_load_fp():
    Set up FP/SIMD for entering the KVM run loop (parse as
    "vcpu_load fp").

    * kvm_arch_vcpu_ctxsync_fp():
    Get FP/SIMD into a safe state for re-enabling interrupts after a
    guest exit back to the run loop.

    For arm64 specifically, this involves updating the host kernel's
    FPSIMD context tracking metadata so that kernel-mode NEON use
    will cause the vcpu's FPSIMD state to be saved back correctly
    into the vcpu struct. This must be done before re-enabling
    interrupts because kernel-mode NEON may be used by softirqs.

    * kvm_arch_vcpu_put_fp():
    Save guest FP/SIMD state back to memory and dissociate from the
    CPU ("vcpu_put fp").

    Also, the arm64 FPSIMD context switch code is updated to enable it
    to save back FPSIMD state for a vcpu, not just current. A few
    helpers drive this:

    * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
    mark this CPU as having context fp (which may belong to a vcpu)
    currently loaded in its registers. This is the non-task
    equivalent of the static function fpsimd_bind_to_cpu() in
    fpsimd.c.

    * task_fpsimd_save():
    exported to allow KVM to save the guest's FPSIMD state back to
    memory on exit from the run loop.

    * fpsimd_flush_state():
    invalidate any context's FPSIMD state that is currently loaded.
    Used to disassociate the vcpu from the CPU regs on run loop exit.

    These changes allow the run loop to enable interrupts (and thus
    softirqs that may use kernel-mode NEON) without having to save the
    guest's FPSIMD state eagerly.

    Some new vcpu_arch fields are added to make all this work. Because
    host FPSIMD state can now be saved back directly into current's
    thread_struct as appropriate, host_cpu_context is no longer used
    for preserving the FPSIMD state. However, it is still needed for
    preserving other things such as the host's system registers. To
    avoid ABI churn, the redundant storage space in host_cpu_context is
    not removed for now.

    arch/arm is not addressed by this patch and continues to use its
    current save/restore logic. It could provide implementations of
    the helpers later if desired.

    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Christoffer Dall
    Reviewed-by: Alex Bennée
    Acked-by: Catalin Marinas
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • In struct vcpu_arch, the debug_flags field is used to store
    debug-related flags about the vcpu state.

    Since we are about to add some more flags related to FPSIMD and
    SVE, it makes sense to add them to the existing flags field rather
    than adding new fields. Since there is only one debug_flags flag
    defined so far, there is plenty of free space for expansion.

    In preparation for adding more flags, this patch renames the
    debug_flags field to simply "flags", and updates comments
    appropriately.

    The flag definitions are also moved to , since
    their presence in was for purely historical
    reasons: these definitions are not used from asm any more, and not
    very likely to be as more Hyp asm is migrated to C.

    KVM_ARM64_DEBUG_DIRTY_SHIFT has not been used since commit
    1ea66d27e7b0 ("arm64: KVM: Move away from the assembly version of
    the world switch"), so this patch gets rid of that too.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Alex Bennée
    Acked-by: Christoffer Dall
    [maz: fixed minor conflict]
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • In preparation for optimising the way KVM manages switching the
    guest and host FPSIMD state, it is necessary to provide a means for
    code outside arch/arm64/kernel/fpsimd.c to restore the user trap
    configuration for SVE correctly for the current task.

    Rather than requiring external code to duplicate the maintenance
    explicitly, this patch moves the trap maintenenace to
    fpsimd_bind_to_cpu(), since it is logically part of the work of
    associating the current task with the cpu.

    Because fpsimd_bind_to_cpu() is rather a cryptic name to publish
    alongside fpsimd_bind_state_to_cpu(), the former function is
    renamed to fpsimd_bind_task_to_cpu() to make its purpose more
    explicit.

    This patch makes appropriate changes to ensure that
    fpsimd_bind_task_to_cpu() is always called alongside
    task_fpsimd_load(), so that the trap maintenance continues to be
    done in every situation where it was done prior to this patch.

    As a side-effect, the metadata updates done by
    fpsimd_bind_task_to_cpu() now change from conditional to
    unconditional in the "already bound" case of sigreturn. This is
    harmless, and a couple of extra stores on this slow path will not
    impact performance. I consider this a reasonable price to pay for
    a slightly cleaner interface.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Marc Zyngier
    Acked-by: Catalin Marinas
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • Currently the FPSIMD handling code uses the condition task->mm ==
    NULL as a hint that task has no FPSIMD register context.

    The ->mm check is only there to filter out tasks that cannot
    possibly have FPSIMD context loaded, for optimisation purposes.
    Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
    saving FPSIMD context back to memory. For these reasons, the ->mm
    checks are not useful, providing that TIF_FOREIGN_FPSTATE is
    maintained in a consistent way for all threads.

    The context switch logic is already deliberately optimised to defer
    reloads of the regs until ret_to_user (or sigreturn as a special
    case), and save them only if they have been previously loaded.
    These paths are the only places where the wrong_task and wrong_cpu
    conditions can be made false, by calling fpsimd_bind_task_to_cpu().
    Kernel threads by definition never reach these paths. As a result,
    the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
    always yield true for kernel threads.

    This patch removes the redundant checks and special-case code,
    ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread
    is scheduled in, and ensures that this flag is set for the init
    task. The fpsimd_flush_task_state() call already present in
    copy_thread() ensures the same for any new task.

    With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
    ensures that no extra context save work is added for kernel
    threads, and eliminates the redundant context saving that may
    currently occur for kernel threads that have acquired an mm via
    use_mm().

    Signed-off-by: Dave Martin
    Reviewed-by: Catalin Marinas
    Reviewed-by: Alex Bennée
    Reviewed-by: Christoffer Dall
    Cc: Catalin Marinas
    Cc: Will Deacon
    Cc: Ard Biesheuvel
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • The init task is started with thread_flags equal to 0, which means
    that TIF_FOREIGN_FPSTATE is initially clear.

    It is theoretically possible (if unlikely) that the init task could
    reach userspace without ever being scheduled out. If this occurs,
    data left in the FPSIMD registers by the kernel could be exposed.

    This patch fixes this anomaly by ensuring that the init task's
    initial TIF_FOREIGN_FPSTATE is set.

    Signed-off-by: Dave Martin
    Fixes: 005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
    Reviewed-by: Catalin Marinas
    Reviewed-by: Alex Bennée
    Cc: Will Deacon
    Cc: Ard Biesheuvel
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • In preparation for allowing non-task (i.e., KVM vcpu) FPSIMD
    contexts to be handled by the fpsimd common code, this patch adapts
    task_fpsimd_save() to save back the currently loaded context,
    removing the explicit dependency on current.

    The relevant storage to write back to in memory is now found by
    examining the fpsimd_last_state percpu struct.

    fpsimd_save() does nothing unless TIF_FOREIGN_FPSTATE is clear, and
    fpsimd_last_state is updated under local_bh_disable() or
    local_irq_disable() everywhere that TIF_FOREIGN_FPSTATE is cleared:
    thus, fpsimd_save() will write back to the correct storage for the
    loaded context.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Marc Zyngier
    Acked-by: Catalin Marinas
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • To make the lazy FPSIMD context switch trap code easier to hack on,
    this patch converts it to C.

    This is not amazingly efficient, but the trap should typically only
    be taken once per host context switch.

    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Alex Bennée
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • KVM/ARM differs from other architectures in having to maintain an
    additional virtual address space from that of the host and the
    guest, because we split the execution of KVM across both EL1 and
    EL2.

    This results in a need to explicitly map data structures into EL2
    (hyp) which are accessed from the hyp code. As we are about to be
    more clever with our FPSIMD handling on arm64, which stores data in
    the task struct and uses thread_info flags, we will have to map
    parts of the currently executing task struct into the EL2 virtual
    address space.

    However, we don't want to do this on every KVM_RUN, because it is a
    fairly expensive operation to walk the page tables, and the common
    execution mode is to map a single thread to a VCPU. By introducing
    a hook that architectures can select with
    HAVE_KVM_VCPU_RUN_PID_CHANGE, we do not introduce overhead for
    other architectures, but have a simple way to only map the data we
    need when required for arm64.

    This patch introduces the framework only, and wires it up in the
    arm/arm64 KVM common code.

    No functional change.

    Signed-off-by: Christoffer Dall
    Signed-off-by: Dave Martin
    Reviewed-by: Marc Zyngier
    Reviewed-by: Alex Bennée
    Signed-off-by: Marc Zyngier

    Christoffer Dall
     
  • This patch uses the new update_thread_flag() helpers to simplify a
    couple of if () set; else clear; constructs.

    No functional change.

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Marc Zyngier
    Acked-by: Catalin Marinas
    Cc: Will Deacon
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • There are a number of bits of code sprinkled around the kernel to
    set a thread flag if a certain condition is true, and clear it
    otherwise.

    To help make those call sites terser and less cumbersome, this
    patch adds a new family of thread flag manipulators

    update*_thread_flag([...,] flag, cond)

    which do the equivalent of:

    if (cond)
    set*_thread_flag([...,] flag);
    else
    clear*_thread_flag([...,] flag);

    Signed-off-by: Dave Martin
    Reviewed-by: Alex Bennée
    Acked-by: Steven Rostedt (VMware)
    Acked-by: Marc Zyngier
    Acked-by: Catalin Marinas
    Acked-by: Peter Zijlstra (Intel)
    Cc: Ingo Molnar
    Cc: Oleg Nesterov
    Signed-off-by: Marc Zyngier

    Dave Martin
     
  • fpsimd_last_state.st is set to NULL as a way of indicating that
    current's FPSIMD registers are no longer loaded in the cpu. In
    particular, this is done when the kernel temporarily uses or
    clobbers the FPSIMD registers for its own purposes, as in CPU PM or
    kernel-mode NEON, resulting in them being populated with garbage
    data not belonging to a task.

    Commit 17eed27b02da ("arm64/sve: KVM: Prevent guests from using
    SVE") factors this operation out as a new helper
    fpsimd_flush_cpu_state() to make it clearer what is being done
    here, and on SVE systems this helper is now used, via
    kvm_fpsimd_flush_cpu_state(), to invalidate the registers after KVM
    has run a vcpu. The reason for this is that KVM does not yet
    understand how to restore the full host SVE registers itself after
    loading the guest FPSIMD context into them.

    This exposes a particular problem: if fpsimd_last_state.st is set
    to NULL without also setting TIF_FOREIGN_FPSTATE, the kernel may
    continue to think that current's FPSIMD registers are live even
    though they have actually been clobbered.

    Prior to the aforementioned commit, the only path where
    fpsimd_last_state.st is set to NULL without setting
    TIF_FOREIGN_FPSTATE is when kernel_neon_begin() is called by a
    kernel thread (where current->mm can be NULL). This does not
    matter, because the only harm is that at context-switch time
    fpsimd_thread_switch() may unnecessarily save the FPSIMD registers
    back to current's thread_struct (even though kernel threads are not
    considered to have any FPSIMD context of their own and the
    registers will never be reloaded).

    Note that although CPU_PM_ENTER lacks the TIF_FOREIGN_FPSTATE
    setting, every CPU passing through that path must subsequently pass
    through CPU_PM_EXIT before it can re-enter the kernel proper.
    CPU_PM_EXIT sets the flag.

    The sve_flush_cpu_state() function added by commit 17eed27b02da
    also lacks the proper maintenance of TIF_FOREIGN_FPSTATE. This may
    cause the bits of a host task's SVE registers that do not alias the
    FPSIMD register file to spontaneously appear zeroed if a KVM vcpu
    runs in the same task in the meantime. Although this effect is
    hidden by the fact that the non-FPSIMD bits of the SVE registers
    are zeroed by a syscall anyway, it is doubtless a bad idea to rely
    on these different code paths interacting correctly under future
    maintenance.

    This patch makes TIF_FOREIGN_FPSTATE an unconditional side-effect
    of fpsimd_flush_cpu_state(), and removes the set_thread_flag()
    calls that become redundant as a result. This ensures that
    TIF_FOREIGN_FPSTATE cannot remain clear if the FPSIMD state in the
    FPSIMD registers is invalid.

    Signed-off-by: Dave Martin
    Reviewed-by: Christoffer Dall
    Reviewed-by: Alex Bennée
    Reviewed-by: Catalin Marinas
    Cc: Will Deacon
    Cc: Ard Biesheuvel
    Signed-off-by: Marc Zyngier

    Dave Martin
     

20 May, 2018

1 commit

  • For historical reasons, we open-code lm_alias() in kvm_ksym_ref().

    Let's use lm_alias() to avoid duplication and make things clearer.

    As we have to pull this from (which is not safe for
    inclusion in assembly), we may as well move the kvm_ksym_ref()
    definition into the existing !__ASSEMBLY__ block.

    Signed-off-by: Mark Rutland
    Cc: Christoffer Dall
    Cc: Marc Zyngier
    Cc: kvmarm@lists.cs.columbia.edu
    Signed-off-by: Marc Zyngier

    Mark Rutland
     

07 May, 2018

1 commit


06 May, 2018

9 commits

  • Pll KVM fixes from Radim Krčmář:
    "ARM:
    - Fix proxying of GICv2 CPU interface accesses
    - Fix crash when switching to BE
    - Track source vcpu git GICv2 SGIs
    - Fix an outdated bit of documentation

    x86:
    - Speed up injection of expired timers (for stable)"

    * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
    KVM: x86: remove APIC Timer periodic/oneshot spikes
    arm64: vgic-v2: Fix proxying of cpuif access
    KVM: arm/arm64: vgic_init: Cleanup reference to process_maintenance
    KVM: arm64: Fix order of vcpu_write_sys_reg() arguments
    KVM: arm/arm64: vgic: Fix source vcpu issues for GICv2 SGI

    Linus Torvalds
     
  • Pull iommu fixes from Joerg Roedel:

    - fix a compile warning in the AMD IOMMU driver with irq remapping
    disabled

    - fix for VT-d interrupt remapping and invalidation size (caused a
    BUG_ON when trying to invalidate more than 4GB)

    - build fix and a regression fix for broken graphics with old DTS for
    the rockchip iommu driver

    - a revert in the PCI window reservation code which fixes a regression
    with VFIO.

    * tag 'iommu-fixes-v4.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
    iommu: rockchip: fix building without CONFIG_OF
    iommu/vt-d: Use WARN_ON_ONCE instead of BUG_ON in qi_flush_dev_iotlb()
    iommu/vt-d: fix shift-out-of-bounds in bug checking
    iommu/dma: Move PCI window region reservation back into dma specific path.
    iommu/rockchip: Make clock handling optional
    iommu/amd: Hide unused iommu_table_lock
    iommu/vt-d: Fix usage of force parameter in intel_ir_reconfigure_irte()

    Linus Torvalds
     
  • Pull x86 fix from Thomas Gleixner:
    "Unbreak the CPUID CPUID_8000_0008_EBX reload which got dropped when
    the evaluation of physical and virtual bits which uses the same CPUID
    leaf was moved out of get_cpu_cap()"

    * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86/cpu: Restore CPUID_8000_0008_EBX reload

    Linus Torvalds
     
  • Pull clocksource fixes from Thomas Gleixner:
    "The recent addition of the early TSC clocksource breaks on machines
    which have an unstable TSC because in case that TSC is disabled, then
    the clocksource selection logic falls back to the early TSC which is
    obviously bogus.

    That also unearthed a few robustness issues in the clocksource
    derating code which are addressed as well"

    * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    clocksource: Rework stale comment
    clocksource: Consistent de-rate when marking unstable
    x86/tsc: Fix mark_tsc_unstable()
    clocksource: Initialize cs->wd_list
    clocksource: Allow clocksource_mark_unstable() on unregistered clocksources
    x86/tsc: Always unregister clocksource_tsc_early

    Linus Torvalds
     
  • Pull irq fix from Thomas Gleixner:
    "A single fix to prevent false positives in the spurious interrupt
    detector when more than a single demultiplex register is evaluated in
    the Qualcom irq combiner driver"

    * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    irqchip/qcom: Fix check for spurious interrupts

    Linus Torvalds
     
  • Pull x86 platform driver fixes from Darren Hart:

    - We missed a case in the Dell config dependencies resulting in a
    possible bad configuration, resolve it by giving up on trying to keep
    DELL_LAPTOP visible in the menu and make it depend on DELL_SMBIOS.

    - Fix a null pointer dereference at module unload for the asus-wireless
    driver.

    * tag 'platform-drivers-x86-v4.17-2' of git://git.infradead.org/linux-platform-drivers-x86:
    platform/x86: Kconfig: Fix dell-laptop dependency chain.
    platform/x86: asus-wireless: Fix NULL pointer dereference

    Linus Torvalds
     
  • Pull USB fixes from Greg KH:
    "Here are some USB driver fixes for 4.17-rc4.

    The majority of them are some USB gadget fixes that missed my last
    pull request. The "largest" patch in here is a fix for the old visor
    driver that syzbot found 6 months or so ago and I finally remembered
    to fix it.

    All of these have been in linux-next with no reported issues"

    * tag 'usb-4.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
    Revert "usb: host: ehci: Use dma_pool_zalloc()"
    usb: typec: tps6598x: handle block reads separately with plain-I2C adapters
    usb: typec: tcpm: Release the role mux when exiting
    USB: Accept bulk endpoints with 1024-byte maxpacket
    xhci: Fix use-after-free in xhci_free_virt_device
    USB: serial: visor: handle potential invalid device configuration
    USB: serial: option: adding support for ublox R410M
    usb: musb: trace: fix NULL pointer dereference in musb_g_tx()
    usb: musb: host: fix potential NULL pointer dereference
    usb: gadget: composite Allow for larger configuration descriptors
    usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue
    usb: dwc3: gadget: dwc3_gadget_del_and_unmap_request() can be static
    usb: dwc2: pci: Fix error return code in dwc2_pci_probe()
    usb: dwc2: WA for Full speed ISOC IN in DDMA mode.
    usb: dwc2: dwc2_vbus_supply_init: fix error check
    usb: gadget: f_phonet: fix pn_net_xmit()'s return type

    Linus Torvalds
     
  • Since the commit "8003c9ae204e: add APIC Timer periodic/oneshot mode VMX
    preemption timer support", a Windows 10 guest has some erratic timer
    spikes.

    Here the results on a 150000 times 1ms timer without any load:
    Before 8003c9ae204e | After 8003c9ae204e
    Max 1834us | 86000us
    Mean 1100us | 1021us
    Deviation 59us | 149us
    Here the results on a 150000 times 1ms timer with a cpu-z stress test:
    Before 8003c9ae204e | After 8003c9ae204e
    Max 32000us | 140000us
    Mean 1006us | 1997us
    Deviation 140us | 11095us

    The root cause of the problem is starting hrtimer with an expiry time
    already in the past can take more than 20 milliseconds to trigger the
    timer function. It can be solved by forward such past timers
    immediately, rather than submitting them to hrtimer_start().
    In case the timer is periodic, update the target expiration and call
    hrtimer_start with it.

    v2: Check if the tsc deadline is already expired. Thank you Mika.
    v3: Execute the past timers immediately rather than submitting them to
    hrtimer_start().
    v4: Rearm the periodic timer with advance_periodic_target_expiration() a
    simpler version of set_target_expiration(). Thank you Paolo.

    Cc: Mika Penttilä
    Cc: Wanpeng Li
    Cc: Paolo Bonzini
    Cc: stable@vger.kernel.org
    Signed-off-by: Anthoine Bourgeois
    8003c9ae204e ("KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support")
    Signed-off-by: Radim Krčmář

    Anthoine Bourgeois
     
  • KVM/arm fixes for 4.17, take #2

    - Fix proxying of GICv2 CPU interface accesses
    - Fix crash when switching to BE
    - Track source vcpu git GICv2 SGIs
    - Fix an outdated bit of documentation

    Radim Krčmář
     

05 May, 2018

9 commits

  • …masahiroy/linux-kbuild

    Pull Kbuild fixes from Masahiro Yamada:

    - remove state comment in modpost

    - extend MAINTAINERS entry to cover modpost and more makefiles

    - fix missed building of SANCOV gcc-plugin

    - replace left-over 'bison' with $(YACC)

    - display short log when generating parer of genksyms

    * tag 'kbuild-fixes-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
    genksyms: fix typo in parse.tab.{c,h} generation rules
    kbuild: replace hardcoded bison in cmd_bison_h with $(YACC)
    gcc-plugins: fix build condition of SANCOV plugin
    MAINTAINERS: Update Kbuild entry with a few paths
    modpost: delete stale comment

    Linus Torvalds
     
  • Pull clk fixes froom Stephen Boyd:
    "A handful of fixes for the stm32mp1 clk driver came in during the
    merge window for the driver that got merged in the merge window.

    Plus a warning fix for unused PM ops and a couple fixes for the meson
    clk driver clk names that went unnoticed with the regmap rework.

    There's also another fix in here for the mux rounding flag which
    wasn't doing what it said it did, but now it does"

    * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
    clk: meson: meson8b: fix meson8b_cpu_clk parent clock name
    clk: meson: meson8b: fix meson8b_fclk_div3_div clock name
    clk: meson: drop meson_aoclk_gate_regmap_ops
    clk: meson: honor CLK_MUX_ROUND_CLOSEST in clk_regmap
    clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux
    clk: cs2000: mark resume function as __maybe_unused
    clk: stm32mp1: remove ck_apb_dbg clock
    clk: stm32mp1: set stgen_k clock as critical
    clk: stm32mp1: add missing tzc2 clock
    clk: stm32mp1: fix SAI3 & SAI4 clocks
    clk: stm32mp1: remove unused dfsdm_src[] const
    clk: stm32mp1: add missing static

    Linus Torvalds
     
  • Pull remoteproc and rpmsg fixes from Bjorn Andersson:

    - fix screw-up when reversing boolean for rproc_stop()

    - add missing OF node refcounting dereferences

    - add missing MODULE_ALIAS in rpmsg_char

    * tag 'rproc-v4.17-1' of git://github.com/andersson/remoteproc:
    rpmsg: added MODULE_ALIAS for rpmsg_char
    remoteproc: qcom: Fix potential device node leaks
    remoteproc: fix crashed parameter logic on stop call

    Linus Torvalds
     
  • Pull drm fixes from Dave Airlie:
    "vmwgfx, i915, vc4, vga dac fixes.

    This seems eerily quiet, so I expect it will explode next week or
    something.

    One i915 model firmware, two vmwgfx fixes, one vc4 fix and one bridge
    leak fix"

    * tag 'drm-fixes-for-v4.17-rc4' of git://people.freedesktop.org/~airlied/linux:
    drm/bridge: vga-dac: Fix edid memory leak
    drm/vc4: Make sure vc4_bo_{inc,dec}_usecnt() calls are balanced
    drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
    drm/vmwgfx: Fix a buffer object leak
    drm/vmwgfx: Clean up fbdev modeset locking

    Linus Torvalds
     
  • Pull tracing fixes from Steven Rostedt:
    "Some of the files in the tracing directory show file mode 0444 when
    they are writable by root. To fix the confusion, they should be 0644.
    Note, either case root can still write to them.

    Zhengyuan asked why I never applied that patch (the first one is from
    2014!). I simply forgot about it. /me lowers head in shame"

    * tag 'trace-v4.17-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
    tracing: Fix the file mode of stack tracer
    ftrace: Have set_graph_* files have normal file modes

    Linus Torvalds
     
  • Pull rdma fixes from Doug Ledford:
    "This is our first pull request of the rc cycle. It's not that it's
    been overly quiet, we were just waiting on a few things before sending
    this off.

    For instance, the 6 patch series from Intel for the hfi1 driver had
    actually been pulled in on Tuesday for a Wednesday pull request, only
    to have Jason notice something I missed, so we held off for some
    testing, and then on Thursday had to respin the series because the
    very first patch needed a minor fix (unnecessary cast is all).

    There is a sizable hns patch series in here, as well as a reasonably
    largish hfi1 patch series, then all of the lines of uapi updates are
    just the change to the new official Linux-OpenIB SPDX tag (a bunch of
    our files had what amounts to a BSD-2-Clause + MIT Warranty statement
    as their license as a result of the initial code submission years ago,
    and the SPDX folks decided it was unique enough to warrant a unique
    tag), then the typical mlx4 and mlx5 updates, and finally some cxgb4
    and core/cache/cma updates to round out the bunch.

    None of it was overly large by itself, but in the 2 1/2 weeks we've
    been collecting patches, it has added up :-/.

    As best I can tell, it's been through 0day (I got a notice about my
    last for-next push, but not for my for-rc push, but Jason seems to
    think that failure messages are prioritized and success messages not
    so much). It's also been through linux-next. And yes, we did notice in
    the context portion of the CMA query gid fix patch that there is a
    dubious BUG_ON() in the code, and have plans to audit our BUG_ON usage
    and remove it anywhere we can.

    Summary:

    - Various build fixes (USER_ACCESS=m and ADDR_TRANS turned off)

    - SPDX license tag cleanups (new tag Linux-OpenIB)

    - RoCE GID fixes related to default GIDs

    - Various fixes to: cxgb4, uverbs, cma, iwpm, rxe, hns (big batch),
    mlx4, mlx5, and hfi1 (medium batch)"

    * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (52 commits)
    RDMA/cma: Do not query GID during QP state transition to RTR
    IB/mlx4: Fix integer overflow when calculating optimal MTT size
    IB/hfi1: Fix memory leak in exception path in get_irq_affinity()
    IB/{hfi1, rdmavt}: Fix memory leak in hfi1_alloc_devdata() upon failure
    IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used
    IB/hfi1: Fix loss of BECN with AHG
    IB/hfi1 Use correct type for num_user_context
    IB/hfi1: Fix handling of FECN marked multicast packet
    IB/core: Make ib_mad_client_id atomic
    iw_cxgb4: Atomically flush per QP HW CQEs
    IB/uverbs: Fix kernel crash during MR deregistration flow
    IB/uverbs: Prevent reregistration of DM_MR to regular MR
    RDMA/mlx4: Add missed RSS hash inner header flag
    RDMA/hns: Fix a couple misspellings
    RDMA/hns: Submit bad wr
    RDMA/hns: Update assignment method for owner field of send wqe
    RDMA/hns: Adjust the order of cleanup hem table
    RDMA/hns: Only assign dqpn if IB_QP_PATH_DEST_QPN bit is set
    RDMA/hns: Remove some unnecessary attr_mask judgement
    RDMA/hns: Only assign mtu if IB_QP_PATH_MTU bit is set
    ...

    Linus Torvalds
     
  • Pull block fixes from Jens Axboe:
    "A collection of fixes that should to into this release. This contains:

    - Set of bcache fixes from Coly, fixing regression in patches that
    went into this series.

    - Set of NVMe fixes by way of Keith.

    - Set of bdi related fixes, one from Jan and two from Tetsuo Handa,
    fixing various issues around device addition/removal.

    - Two block inflight fixes from Omar, fixing issues around the
    transition to using tags for blk-mq inflight accounting that we
    did a few releases ago"

    * tag 'for-linus-20180504' of git://git.kernel.dk/linux-block:
    bdi: Fix oops in wb_workfn()
    nvmet: switch loopback target state to connecting when resetting
    nvme/multipath: Fix multipath disabled naming collisions
    nvme/multipath: Disable runtime writable enabling parameter
    nvme: Set integrity flag for user passthrough commands
    nvme: fix potential memory leak in option parsing
    bdi: Fix use after free bug in debugfs_remove()
    bdi: wake up concurrent wb_shutdown() callers.
    bcache: use pr_info() to inform duplicated CACHE_SET_IO_DISABLE set
    bcache: set dc->io_disable to true in conditional_stop_bcache_device()
    bcache: add wait_for_kthread_stop() in bch_allocator_thread()
    bcache: count backing device I/O error for writeback I/O
    bcache: set CACHE_SET_IO_DISABLE in bch_cached_dev_error()
    bcache: store disk name in struct cache and struct cached_dev
    blk-mq: fix sysfs inflight counter
    blk-mq: count allocated but not started requests in iostats inflight

    Linus Torvalds
     
  • Pull xfs fixes from Darrick Wong:
    "I've got one more bug fix for xfs for 4.17-rc4, which caps the amount
    of data we try to handle in one dedupe request so that userspace can't
    livelock the kernel.

    This series has been run through a full xfstests run during the week
    and through a quick xfstests run against this morning's master, with
    no ajor failures reported.

    Summary:

    - Cap the maximum length of a deduplication request at MAX_RW_COUNT/2
    to avoid kernel livelock due to excessively large IO requests"

    * tag 'xfs-4.17-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
    xfs: cap the length of deduplication requests

    Linus Torvalds
     
  • Pull btrfs fixes from David Sterba:
    "Two regression fixes and one fix for stable"

    * tag 'for-4.17-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
    Btrfs: send, fix missing truncate for inode with prealloc extent past eof
    btrfs: Take trans lock before access running trans in check_delayed_ref
    btrfs: Fix wrong first_key parameter in replace_path

    Linus Torvalds