1. 10 Jun, 2020 1 commit
  2. 09 Jun, 2020 4 commits
    • Marc Zyngier's avatar
      KVM: arm64: Remove host_cpu_context member from vcpu structure · 07da1ffa
      Marc Zyngier authored
      For very long, we have kept this pointer back to the per-cpu
      host state, despite having working per-cpu accessors at EL2
      for some time now.
      
      Recent investigations have shown that this pointer is easy
      to abuse in preemptible context, which is a sure sign that
      it would better be gone. Not to mention that a per-cpu
      pointer is faster to access at all times.
      Reported-by: default avatarAndrew Scull <ascull@google.com>
      Acked-by: Mark Rutland <mark.rutland@arm.com
      Reviewed-by: default avatarAndrew Scull <ascull@google.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      07da1ffa
    • Marc Zyngier's avatar
      KVM: arm64: Stop sparse from moaning at __hyp_this_cpu_ptr · b990d37f
      Marc Zyngier authored
      Sparse complains that __hyp_this_cpu_ptr() returns something
      that is flagged noderef and not in the correct address space
      (both being the result of the __percpu annotation).
      
      Pretend that __hyp_this_cpu_ptr() knows what it is doing by
      forcefully casting the pointer with __kernel __force.
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      b990d37f
    • Marc Zyngier's avatar
      KVM: arm64: Handle PtrAuth traps early · 29eb5a3c
      Marc Zyngier authored
      The current way we deal with PtrAuth is a bit heavy handed:
      
      - We forcefully save the host's keys on each vcpu_load()
      - Handling the PtrAuth trap forces us to go all the way back
        to the exit handling code to just set the HCR bits
      
      Overall, this is pretty cumbersome. A better approach would be
      to handle it the same way we deal with the FPSIMD registers:
      
      - On vcpu_load() disable PtrAuth for the guest
      - On first use, save the host's keys, enable PtrAuth in the
        guest
      
      Crucially, this can happen as a fixup, which is done very early
      on exit. We can then reenter the guest immediately without
      leaving the hypervisor role.
      
      Another thing is that it simplify the rest of the host handling:
      exiting all the way to the host means that the only possible
      outcome for this trap is to inject an UNDEF.
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      29eb5a3c
    • Marc Zyngier's avatar
      KVM: arm64: Save the host's PtrAuth keys in non-preemptible context · ef3e40a7
      Marc Zyngier authored
      When using the PtrAuth feature in a guest, we need to save the host's
      keys before allowing the guest to program them. For that, we dump
      them in a per-CPU data structure (the so called host context).
      
      But both call sites that do this are in preemptible context,
      which may end up in disaster should the vcpu thread get preempted
      before reentering the guest.
      
      Instead, save the keys eagerly on each vcpu_load(). This has an
      increased overhead, but is at least safe.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      ef3e40a7
  3. 31 May, 2020 1 commit
  4. 28 May, 2020 7 commits
  5. 25 May, 2020 3 commits
  6. 16 May, 2020 14 commits
  7. 10 May, 2020 7 commits
    • Linus Torvalds's avatar
      Linux 5.7-rc5 · 2ef96a5b
      Linus Torvalds authored
      2ef96a5b
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c14cab26
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "A set of fixes for x86:
      
         - Ensure that direct mapping alias is always flushed when changing
           page attributes. The optimization for small ranges failed to do so
           when the virtual address was in the vmalloc or module space.
      
         - Unbreak the trace event registration for syscalls without arguments
           caused by the refactoring of the SYSCALL_DEFINE0() macro.
      
         - Move the printk in the TSC deadline timer code to a place where it
           is guaranteed to only be called once during boot and cannot be
           rearmed by clearing warn_once after boot. If it's invoked post boot
           then lockdep rightfully complains about a potential deadlock as the
           calling context is different.
      
         - A series of fixes for objtool and the ORC unwinder addressing
           variety of small issues:
      
             - Stack offset tracking for indirect CFAs in objtool ignored
               subsequent pushs and pops
      
             - Repair the unwind hints in the register clearing entry ASM code
      
             - Make the unwinding in the low level exit to usermode code stop
               after switching to the trampoline stack. The unwind hint is no
               longer valid and the ORC unwinder emits a warning as it can't
               find the registers anymore.
      
             - Fix unwind hints in switch_to_asm() and rewind_stack_do_exit()
               which caused objtool to generate bogus ORC data.
      
             - Prevent unwinder warnings when dumping the stack of a
               non-current task as there is no way to be sure about the
               validity because the dumped stack can be a moving target.
      
             - Make the ORC unwinder behave the same way as the frame pointer
               unwinder when dumping an inactive tasks stack and do not skip
               the first frame.
      
             - Prevent ORC unwinding before ORC data has been initialized
      
             - Immediately terminate unwinding when a unknown ORC entry type
               is found.
      
             - Prevent premature stop of the unwinder caused by IRET frames.
      
             - Fix another infinite loop in objtool caused by a negative
               offset which was not catched.
      
             - Address a few build warnings in the ORC unwinder and add
               missing static/ro_after_init annotations"
      
      * tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES
        x86/apic: Move TSC deadline timer debug printk
        ftrace/x86: Fix trace event registration for syscalls without arguments
        x86/mm/cpa: Flush direct map alias during cpa
        objtool: Fix infinite loop in for_offset_range()
        x86/unwind/orc: Fix premature unwind stoppage due to IRET frames
        x86/unwind/orc: Fix error path for bad ORC entry type
        x86/unwind/orc: Prevent unwinding before ORC initialization
        x86/unwind/orc: Don't skip the first frame for inactive tasks
        x86/unwind: Prevent false warnings for non-current tasks
        x86/unwind/orc: Convert global variables to static
        x86/entry/64: Fix unwind hints in rewind_stack_do_exit()
        x86/entry/64: Fix unwind hints in __switch_to_asm()
        x86/entry/64: Fix unwind hints in kernel exit path
        x86/entry/64: Fix unwind hints in register clearing code
        objtool: Fix stack offset tracking for indirect CFAs
      c14cab26
    • Linus Torvalds's avatar
      Merge tag 'objtool-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 8b000832
      Linus Torvalds authored
      Pull objtool fix from Thomas Gleixner:
       "A single fix for objtool to prevent an infinite loop in the
        jump table search which can be triggered when building the
        kernel with '-ffunction-sections'"
      
      * tag 'objtool-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        objtool: Fix infinite loop in find_jump_table()
      8b000832
    • Linus Torvalds's avatar
      Merge tag 'locking-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · bd2049f8
      Linus Torvalds authored
      Pull locking fix from Thomas Gleixner:
       "A single fix for the fallout of the recent futex uacess rework.
      
        With those changes GCC9 fails to analyze arch_futex_atomic_op_inuser()
        correctly and emits a 'maybe unitialized' warning. While we usually
        ignore compiler stupidity the conditional store is pointless anyway
        because the correct case has to store. For the fault case the extra
        store does no harm"
      
      * tag 'locking-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        ARM: futex: Address build warning
      bd2049f8
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 27d2dcb1
      Linus Torvalds authored
      Pull iommu fixes from Joerg Roedel:
      
       - Race condition fixes for the AMD IOMMU driver.
      
         These are five patches fixing two race conditions around
         increase_address_space(). The first race condition was around the
         non-atomic update of the domain page-table root pointer and the
         variable containing the page-table depth (called mode). This is fixed
         now be merging page-table root and mode into one 64-bit field which
         is read/written atomically.
      
         The second race condition was around updating the page-table root
         pointer and making it public before the hardware caches were flushed.
         This could cause addresses to be mapped and returned to drivers which
         are not reachable by IOMMU hardware yet, causing IO page-faults. This
         is fixed too by adding the necessary flushes before a new page-table
         root is published.
      
         Related to the race condition fixes these patches also add a missing
         domain_flush_complete() barrier to update_domain() and a fix to bail
         out of the loop which tries to increase the address space when the
         call to increase_address_space() fails.
      
         Qian was able to trigger the race conditions under high load and
         memory pressure within a few days of testing. He confirmed that he
         has seen no issues anymore with the fixes included here.
      
       - Fix for a list-handling bug in the VirtIO IOMMU driver.
      
      * tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/virtio: Reverse arguments to list_add
        iommu/amd: Do not flush Device Table in iommu_map_page()
        iommu/amd: Update Device Table in increase_address_space()
        iommu/amd: Call domain_flush_complete() in update_domain()
        iommu/amd: Do not loop forever when trying to increase address space
        iommu/amd: Fix race in increase_address_space()/fetch_pte()
      27d2dcb1
    • Linus Torvalds's avatar
      Merge tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block · 0a85ed6e
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
      
       - a small series fixing a use-after-free of bdi name (Christoph,Yufen)
      
       - NVMe fix for a regression with the smaller CQ update (Alexey)
      
       - NVMe fix for a hang at namespace scanning error recovery (Sagi)
      
       - fix race with blk-iocost iocg->abs_vdebt updates (Tejun)
      
      * tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block:
        nvme: fix possible hang when ns scanning fails during error recovery
        nvme-pci: fix "slimmer CQ head update"
        bdi: add a ->dev_name field to struct backing_dev_info
        bdi: use bdi_dev_name() to get device name
        bdi: move bdi_dev_name out of line
        vboxsf: don't use the source name in the bdi name
        iocost: protect iocg->abs_vdebt with iocg->waitq.lock
      0a85ed6e
    • Linus Torvalds's avatar
      gcc-10: mark more functions __init to avoid section mismatch warnings · e99332e7
      Linus Torvalds authored
      It seems that for whatever reason, gcc-10 ends up not inlining a couple
      of functions that used to be inlined before.  Even if they only have one
      single callsite - it looks like gcc may have decided that the code was
      unlikely, and not worth inlining.
      
      The code generation difference is harmless, but caused a few new section
      mismatch errors, since the (now no longer inlined) function wasn't in
      the __init section, but called other init functions:
      
         Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem()
         Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap()
         Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap()
      
      So add the appropriate __init annotation to make modpost not complain.
      In both cases there were trivially just a single callsite from another
      __init function.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e99332e7
  8. 09 May, 2020 3 commits
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · 2e28f3b1
      Linus Torvalds authored
      Pull RISC-V fixes from Palmer Dabbelt:
       "A smattering of fixes and cleanups:
      
         - Dead code removal.
      
         - Exporting riscv_cpuid_to_hartid_mask for modules.
      
         - Per-CPU tracking of ISA features.
      
         - Setting max_pfn correctly when probing memory.
      
         - Adding a note to the VDSO so glibc can check the kernel's version
           without a uname().
      
         - A fix to force the bootloader to initialize the boot spin tables,
           which still get used as a fallback when SBI-0.1 is enabled"
      
      * tag 'riscv-for-linus-5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        RISC-V: Remove unused code from STRICT_KERNEL_RWX
        riscv: force __cpu_up_ variables to put in data section
        riscv: add Linux note to vdso
        riscv: set max_pfn to the PFN of the last page
        RISC-V: Remove N-extension related defines
        RISC-V: Add bitmap reprensenting ISA features common across CPUs
        RISC-V: Export riscv_cpuid_to_hartid_mask() API
      2e28f3b1
    • Linus Torvalds's avatar
      gcc-10: avoid shadowing standard library 'free()' in crypto · 1a263ae6
      Linus Torvalds authored
      gcc-10 has started warning about conflicting types for a few new
      built-in functions, particularly 'free()'.
      
      This results in warnings like:
      
         crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]
      
      because the crypto layer had its local freeing functions called
      'free()'.
      
      Gcc-10 is in the wrong here, since that function is marked 'static', and
      thus there is no chance of confusion with any standard library function
      namespace.
      
      But the simplest thing to do is to just use a different name here, and
      avoid this gcc mis-feature.
      
      [ Side note: gcc knowing about 'free()' is in itself not the
        mis-feature: the semantics of 'free()' are special enough that a
        compiler can validly do special things when seeing it.
      
        So the mis-feature here is that gcc thinks that 'free()' is some
        restricted name, and you can't shadow it as a local static function.
      
        Making the special 'free()' semantics be a function attribute rather
        than tied to the name would be the much better model ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1a263ae6
    • Linus Torvalds's avatar
      gcc-10: disable 'restrict' warning for now · adc71920
      Linus Torvalds authored
      gcc-10 now warns about passing aliasing pointers to functions that take
      restricted pointers.
      
      That's actually a great warning, and if we ever start using 'restrict'
      in the kernel, it might be quite useful.  But right now we don't, and it
      turns out that the only thing this warns about is an idiom where we have
      declared a few functions to be "printf-like" (which seems to make gcc
      pick up the restricted pointer thing), and then we print to the same
      buffer that we also use as an input.
      
      And people do that as an odd concatenation pattern, with code like this:
      
          #define sysfs_show_gen_prop(buffer, fmt, ...) \
              snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
      
      where we have 'buffer' as both the destination of the final result, and
      as the initial argument.
      
      Yes, it's a bit questionable.  And outside of the kernel, people do have
      standard declarations like
      
          int snprintf( char *restrict buffer, size_t bufsz,
                        const char *restrict format, ... );
      
      where that output buffer is marked as a restrict pointer that cannot
      alias with any other arguments.
      
      But in the context of the kernel, that 'use snprintf() to concatenate to
      the end result' does work, and the pattern shows up in multiple places.
      And we have not marked our own version of snprintf() as taking restrict
      pointers, so the warning is incorrect for now, and gcc picks it up on
      its own.
      
      If we do start using 'restrict' in the kernel (and it might be a good
      idea if people find places where it matters), we'll need to figure out
      how to avoid this issue for snprintf and friends.  But in the meantime,
      this warning is not useful.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      adc71920