1. 09 12月, 2017 2 次提交
  2. 07 12月, 2017 10 次提交
    • A
      ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds · 863204cf
      Arnd Bergmann 提交于
      In configurations without CONFIG_OMAP3 but with secure RAM support,
      we now run into a link failure:
      
      arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
      omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
      
      The omap3_save_secure_ram() function is only called from the OMAP34xx
      power management code, so we can simply hide that function in the
      appropriate #ifdef.
      
      Fixes: d09220a8 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
      Acked-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NDan Murphy <dmurphy@ti.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      863204cf
    • R
      arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv · c5bbf358
      Rob Herring 提交于
      "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
      property. This is probably because the binding was the precursor to the phy
      binding.
      
      Fixes the following warning in nspire dts files:
      
      Warning (phys_property): Missing property '#phy-cells' in node ...
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      c5bbf358
    • H
      s390: fix compat system call table · e779498d
      Heiko Carstens 提交于
      When wiring up the socket system calls the compat entries were
      incorrectly set. Not all of them point to the corresponding compat
      wrapper functions, which clear the upper 33 bits of user space
      pointers, like it is required.
      
      Fixes: 977108f8 ("s390: wire up separate socketcalls system calls")
      Cc: <stable@vger.kernel.org> # v4.3+
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e779498d
    • A
      x86/vdso: Change time() prototype to match __vdso_time() · 88edb57d
      Arnd Bergmann 提交于
      gcc-8 warns that time() is an alias for __vdso_time() but the two
      have different prototypes:
      
        arch/x86/entry/vdso/vclock_gettime.c:327:5: error: 'time' alias between functions of incompatible types 'int(time_t *)' {aka 'int(long int *)'} and 'time_t(time_t *)' {aka 'long int(long int *)'} [-Werror=attribute-alias]
         int time(time_t *t)
             ^~~~
        arch/x86/entry/vdso/vclock_gettime.c:318:16: note: aliased declaration here
      
      I could not figure out whether this is intentional, but I see that
      changing it to return time_t avoids the warning.
      
      Returning 'int' from time() is also a bit questionable, as it causes an
      overflow in y2038 even on 64-bit architectures that use a 64-bit time_t
      type. On 32-bit architecture with 64-bit time_t, time() should always
      be implement by the C library by calling a (to be added) clock_gettime()
      variant that takes a sufficiently wide argument.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Link: http://lkml.kernel.org/r/20171204150203.852959-1-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      88edb57d
    • D
      arm64/sve: Avoid dereference of dead task_struct in KVM guest entry · cb968afc
      Dave Martin 提交于
      When deciding whether to invalidate FPSIMD state cached in the cpu,
      the backend function sve_flush_cpu_state() attempts to dereference
      __this_cpu_read(fpsimd_last_state).  However, this is not safe:
      there is no guarantee that this task_struct pointer is still valid,
      because the task could have exited in the meantime.
      
      This means that we need another means to get the appropriate value
      of TIF_SVE for the associated task.
      
      This patch solves this issue by adding a cached copy of the TIF_SVE
      flag in fpsimd_last_state, which we can check without dereferencing
      the task pointer.
      
      In particular, although this patch is not a KVM fix per se, this
      means that this check is now done safely in the KVM world switch
      path (which is currently the only user of this code).
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      cb968afc
    • C
      x86: Fix Sparse warnings about non-static functions · d553d03f
      Colin Ian King 提交于
      Functions x86_vector_debug_show(), uv_handle_nmi() and uv_nmi_setup_common()
      are local to the source and do not need to be in global scope, so make them
      static.
      
      Fixes up various sparse warnings.
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Acked-by: NMike Travis <mike.travis@hpe.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Kosina <trivial@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <russ.anderson@hpe.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kernel-janitors@vger.kernel.org
      Cc: travis@sgi.com
      Link: http://lkml.kernel.org/r/20171206173358.24388-1-colin.king@canonical.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d553d03f
    • W
      arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb · d96cc49b
      Will Deacon 提交于
      enter_lazy_tlb is called when a kernel thread rides on the back of
      another mm, due to a context switch or an explicit call to unuse_mm
      where a call to switch_mm is elided.
      
      In these cases, it's important to keep the saved ttbr value up to date
      with the active mm, otherwise we can end up with a stale value which
      points to a potentially freed page table.
      
      This patch implements enter_lazy_tlb for arm64, so that the saved ttbr0
      is kept up-to-date with the active mm for kernel threads.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vinayak Menon <vinmenon@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 39bc88e5 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NVinayak Menon <vinmenon@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d96cc49b
    • W
      arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm · 0adbdfde
      Will Deacon 提交于
      update_saved_ttbr0 mandates that mm->pgd is not swapper, since swapper
      contains kernel mappings and should never be installed into ttbr0. However,
      this means that callers must avoid passing the init_mm to update_saved_ttbr0
      which in turn can cause the saved ttbr0 value to be out-of-date in the context
      of the idle thread. For example, EFI runtime services may leave the saved ttbr0
      pointing at the EFI page table, and kernel threads may end up with stale
      references to freed page tables.
      
      This patch changes update_saved_ttbr0 so that the init_mm points the saved
      ttbr0 value to the empty zero page, which always exists and never contains
      valid translations. EFI and switch can then call into update_saved_ttbr0
      unconditionally.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vinayak Menon <vinmenon@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 39bc88e5 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NVinayak Menon <vinmenon@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0adbdfde
    • D
      arm64: fpsimd: Abstract out binding of task's fpsimd context to the cpu. · 8884b7bd
      Dave Martin 提交于
      There is currently some duplicate logic to associate current's
      FPSIMD context with the cpu when loading FPSIMD state into the cpu
      regs.
      
      Subsequent patches will update that logic, so in order to ensure it
      only needs to be done in one place, this patch factors the relevant
      code out into a new function fpsimd_bind_to_cpu().
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      8884b7bd
    • D
      arm64: fpsimd: Prevent registers leaking from dead tasks · 071b6d4a
      Dave Martin 提交于
      Currently, loading of a task's fpsimd state into the CPU registers
      is skipped if that task's state is already present in the registers
      of that CPU.
      
      However, the code relies on the struct fpsimd_state * (and by
      extension struct task_struct *) to unambiguously identify a task.
      
      There is a particular case in which this doesn't work reliably:
      when a task exits, its task_struct may be recycled to describe a
      new task.
      
      Consider the following scenario:
      
       1) Task P loads its fpsimd state onto cpu C.
              per_cpu(fpsimd_last_state, C) := P;
              P->thread.fpsimd_state.cpu := C;
      
       2) Task X is scheduled onto C and loads its fpsimd state on C.
              per_cpu(fpsimd_last_state, C) := X;
              X->thread.fpsimd_state.cpu := C;
      
       3) X exits, causing X's task_struct to be freed.
      
       4) P forks a new child T, which obtains X's recycled task_struct.
      	T == X.
      	T->thread.fpsimd_state.cpu == C (inherited from P).
      
       5) T is scheduled on C.
      	T's fpsimd state is not loaded, because
      	per_cpu(fpsimd_last_state, C) == T (== X) &&
      	T->thread.fpsimd_state.cpu == C.
      
              (This is the check performed by fpsimd_thread_switch().)
      
      So, T gets X's registers because the last registers loaded onto C
      were those of X, in (2).
      
      This patch fixes the problem by ensuring that the sched-in check
      fails in (5): fpsimd_flush_task_state(T) is called when T is
      forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
      This relies on the fact that T is not schedulable until after
      copy_thread() completes.
      
      Once T's fpsimd state has been loaded on some CPU C there may still
      be other cpus D for which per_cpu(fpsimd_last_state, D) ==
      &X->thread.fpsimd_state.  But D is necessarily != C in this case,
      and the check in (5) must fail.
      
      An alternative fix would be to do refcounting on task_struct.  This
      would result in each CPU holding a reference to the last task whose
      fpsimd state was loaded there.  It's not clear whether this is
      preferable, and it involves higher overhead than the fix proposed
      in this patch.  It would also move all the task_struct freeing
      work into the context switch critical section, or otherwise some
      deferred cleanup mechanism would need to be introduced, neither of
      which seems obviously justified.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 005f78cd ("arm64: defer reloading a task's FPSIMD state to userland resume")
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: word-smithed the comment so it makes more sense]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      071b6d4a
  3. 06 12月, 2017 19 次提交
  4. 05 12月, 2017 9 次提交