1. 14 5月, 2018 3 次提交
  2. 12 5月, 2018 2 次提交
  3. 09 5月, 2018 2 次提交
  4. 08 5月, 2018 3 次提交
    • U
      arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan · 9a62dcf4
      Uwe Kleine-König 提交于
      Commit d50f4630 ("arm: dts: Remove p1010-flexcan compatible from imx
      series dts") removed the fallback compatible "fsl,p1010-flexcan" from
      the imx device trees. As the flexcan cores on i.MX25, i.MX35 and i.MX53
      are identical, introduce the first as fallback for the two latter ones.
      
      Fixes: d50f4630 ("arm: dts: Remove p1010-flexcan compatible from imx series dts")
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      9a62dcf4
    • M
      powerpc/pseries: Fix CONFIG_NUMA=n build · 6c0a8f6b
      Michael Ellerman 提交于
      The build is failing with CONFIG_NUMA=n and some compiler versions:
      
        arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu':
        hotplug-cpu.c:(.text+0x12c): undefined reference to `timed_topology_update'
        arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_cpu_remove':
        hotplug-cpu.c:(.text+0x400): undefined reference to `timed_topology_update'
      
      Fix it by moving the empty version of timed_topology_update() into the
      existing #ifdef block, which has the right guard of SPLPAR && NUMA.
      
      Fixes: cee5405d ("powerpc/hotplug: Improve responsiveness of hotplug change")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6c0a8f6b
    • V
      x86/xen: Reset VCPU0 info pointer after shared_info remap · d1ecfa9d
      van der Linden, Frank 提交于
      This patch fixes crashes during boot for HVM guests on older (pre HVM
      vector callback) Xen versions. Without this, current kernels will always
      fail to boot on those Xen versions.
      
      Sample stack trace:
      
         BUG: unable to handle kernel paging request at ffffffffff200000
         IP: __xen_evtchn_do_upcall+0x1e/0x80
         PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0
          Oops: 0002 [#1] SMP PTI
         Modules linked in:
         CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1
         Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016
         task: ffff88002531d700 task.stack: ffffc90000480000
         RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80
         RSP: 0000:ffff880025403ef0 EFLAGS: 00010046
         RAX: ffffffff813cc760 RBX: ffffffffff200000 RCX: ffffc90000483ef0
         RDX: ffff880020540a00 RSI: ffff880023c78000 RDI: 000000000000001c
         RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
         R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
         R13: ffff880025403f5c R14: 0000000000000000 R15: 0000000000000000
         FS:  0000000000000000(0000) GS:ffff880025400000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: ffffffffff200000 CR3: 0000000001e0a000 CR4: 00000000000006f0
          Call Trace:
         <IRQ>
         do_hvm_evtchn_intr+0xa/0x10
         __handle_irq_event_percpu+0x43/0x1a0
         handle_irq_event_percpu+0x20/0x50
         handle_irq_event+0x39/0x60
         handle_fasteoi_irq+0x80/0x140
         handle_irq+0xaf/0x120
         do_IRQ+0x41/0xd0
         common_interrupt+0x7d/0x7d
         </IRQ>
      
      During boot, the HYPERVISOR_shared_info page gets remapped to make it work
      with KASLR. This means that any pointer derived from it needs to be
      adjusted.
      
      The only value that this applies to is the vcpu_info pointer for VCPU 0.
      For PV and HVM with the callback vector feature, this gets done via the
      smp_ops prepare_boot_cpu callback. Older Xen versions do not support the
      HVM callback vector, so there is no Xen-specific smp_ops set up in that
      scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper
      value, and the first reference of it will be bad. Fix this by resetting it
      immediately after the remap.
      Signed-off-by: NFrank van der Linden <fllinden@amazon.com>
      Reviewed-by: NEduardo Valentin <eduval@amazon.com>
      Reviewed-by: NAlakesh Haloi <alakeshh@amazon.com>
      Reviewed-by: NVallish Vaidyeshwara <vallish@amazon.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      d1ecfa9d
  5. 07 5月, 2018 3 次提交
  6. 06 5月, 2018 3 次提交
    • A
      KVM: x86: remove APIC Timer periodic/oneshot spikes · ecf08dad
      Anthoine Bourgeois 提交于
      Since the commit "8003c9ae: 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 8003c9ae | After 8003c9ae
      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 8003c9ae | After 8003c9ae
      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ä <mika.penttila@nextfour.com>
      Cc: Wanpeng Li <kernellwp@gmail.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAnthoine Bourgeois <anthoine.bourgeois@blade-group.com>
      8003c9ae ("KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support")
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      ecf08dad
    • J
      sh: mm: Fix unprotected access to struct device · b9826a49
      Jacopo Mondi 提交于
      With commit ce883130 ("arch/sh: make the DMA mapping
      operations observe dev->dma_pfn_offset") the generic DMA allocation
      function on which the SH 'dma_alloc_coherent()' function relies on,
      accesses the 'dma_pfn_offset' field of struct device.
      
      Unfortunately the 'dma_generic_alloc_coherent()' function is called from
      several places with a NULL struct device argument, halting the CPU
      during the boot process.
      
      This patch fixes the issue by protecting access to dev->dma_pfn_offset,
      with a trivial check for validity. It also passes a valid 'struct device'
      in the 'platform_resource_setup_memory()' function which is the main user
      of 'dma_alloc_coherent()', and inserts a WARN_ON() check to remind to future
      (and existing) bogus users of this function to provide a valid 'struct device'
      whenever possible.
      
      Fixes: ce883130 ("arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset")
      Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Signed-off-by: NRich Felker <dalias@libc.org>
      b9826a49
    • R
      sh: fix build failure for J2 cpu with SMP disabled · 6cb46597
      Rich Felker 提交于
      The sh asm/smp.h defines a fallback hard_smp_processor_id macro for
      the !SMP case, but linux/smp.h never includes asm/smp.h in the !SMP
      case.
      Signed-off-by: NRich Felker <dalias@libc.org>
      6cb46597
  7. 05 5月, 2018 5 次提交
    • J
      x86/vdso: Remove unused file · e0f6d1a5
      Jann Horn 提交于
      commit da861e18 ("x86, vdso: Get rid of the fake section mechanism")
      left this file behind; nothing is using it anymore.
      Signed-off-by: NJann Horn <jannh@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: luto@amacapital.net
      Link: http://lkml.kernel.org/r/20180504175935.104085-1-jannh@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      e0f6d1a5
    • P
      perf/x86/cstate: Fix possible Spectre-v1 indexing for pkg_msr · a5f81290
      Peter Zijlstra 提交于
      > arch/x86/events/intel/cstate.c:307 cstate_pmu_event_init() warn: potential spectre issue 'pkg_msr' (local cap)
      
      Userspace controls @attr, sanitize cfg (attr->config) before using it
      to index an array.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      a5f81290
    • P
      perf/x86/msr: Fix possible Spectre-v1 indexing in the MSR driver · 06ce6e9b
      Peter Zijlstra 提交于
      > arch/x86/events/msr.c:178 msr_event_init() warn: potential spectre issue 'msr' (local cap)
      
      Userspace controls @attr, sanitize cfg (attr->config) before using it
      to index an array.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      06ce6e9b
    • P
      perf/x86: Fix possible Spectre-v1 indexing for x86_pmu::event_map() · 46b1b577
      Peter Zijlstra 提交于
      > arch/x86/events/intel/cstate.c:307 cstate_pmu_event_init() warn: potential spectre issue 'pkg_msr' (local cap)
      > arch/x86/events/intel/core.c:337 intel_pmu_event_map() warn: potential spectre issue 'intel_perfmon_event_map'
      > arch/x86/events/intel/knc.c:122 knc_pmu_event_map() warn: potential spectre issue 'knc_perfmon_event_map'
      > arch/x86/events/intel/p4.c:722 p4_pmu_event_map() warn: potential spectre issue 'p4_general_events'
      > arch/x86/events/intel/p6.c:116 p6_pmu_event_map() warn: potential spectre issue 'p6_perfmon_event_map'
      > arch/x86/events/amd/core.c:132 amd_pmu_event_map() warn: potential spectre issue 'amd_perfmon_event_map'
      
      Userspace controls @attr, sanitize @attr->config before passing it on
      to x86_pmu::event_map().
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      46b1b577
    • P
      perf/x86: Fix possible Spectre-v1 indexing for hw_perf_event cache_* · ef9ee4ad
      Peter Zijlstra 提交于
      > arch/x86/events/core.c:319 set_ext_hw_attr() warn: potential spectre issue 'hw_cache_event_ids[cache_type]' (local cap)
      > arch/x86/events/core.c:319 set_ext_hw_attr() warn: potential spectre issue 'hw_cache_event_ids' (local cap)
      > arch/x86/events/core.c:328 set_ext_hw_attr() warn: potential spectre issue 'hw_cache_extra_regs[cache_type]' (local cap)
      > arch/x86/events/core.c:328 set_ext_hw_attr() warn: potential spectre issue 'hw_cache_extra_regs' (local cap)
      
      Userspace controls @config which contains 3 (byte) fields used for a 3
      dimensional array deref.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ef9ee4ad
  8. 04 5月, 2018 2 次提交
    • J
      arm64: vgic-v2: Fix proxying of cpuif access · b220244d
      James Morse 提交于
      Proxying the cpuif accesses at EL2 makes use of vcpu_data_guest_to_host
      and co, which check the endianness, which call into vcpu_read_sys_reg...
      which isn't mapped at EL2 (it was inlined before, and got moved OoL
      with the VHE optimizations).
      
      The result is of course a nice panic. Let's add some specialized
      cruft to keep the broken platforms that require this hack alive.
      
      But, this code used vcpu_data_guest_to_host(), which expected us to
      write the value to host memory, instead we have trapped the guest's
      read or write to an mmio-device, and are about to replay it using the
      host's readl()/writel() which also perform swabbing based on the host
      endianness. This goes wrong when both host and guest are big-endian,
      as readl()/writel() will undo the guest's swabbing, causing the
      big-endian value to be written to device-memory.
      
      What needs doing?
      A big-endian guest will have pre-swabbed data before storing, undo this.
      If its necessary for the host, writel() will re-swab it.
      
      For a read a big-endian guest expects to swab the data after the load.
      The hosts's readl() will correct for host endianness, giving us the
      device-memory's value in the register. For a big-endian guest, swab it
      as if we'd only done the load.
      
      For a little-endian guest, nothing needs doing as readl()/writel() leave
      the correct device-memory value in registers.
      
      Tested on Juno with that rarest of things: a big-endian 64K host.
      Based on a patch from Marc Zyngier.
      Reported-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Fixes: bf8feb39 ("arm64: KVM: vgic-v2: Add GICV access from HYP")
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      b220244d
    • J
      KVM: arm64: Fix order of vcpu_write_sys_reg() arguments · 1975fa56
      James Morse 提交于
      A typo in kvm_vcpu_set_be()'s call:
      | vcpu_write_sys_reg(vcpu, SCTLR_EL1, sctlr)
      causes us to use the 32bit register value as an index into the sys_reg[]
      array, and sail off the end of the linear map when we try to bring up
      big-endian secondaries.
      
      | Unable to handle kernel paging request at virtual address ffff80098b982c00
      | Mem abort info:
      |  ESR = 0x96000045
      |  Exception class = DABT (current EL), IL = 32 bits
      |   SET = 0, FnV = 0
      |   EA = 0, S1PTW = 0
      | Data abort info:
      |   ISV = 0, ISS = 0x00000045
      |   CM = 0, WnR = 1
      | swapper pgtable: 4k pages, 48-bit VAs, pgdp = 000000002ea0571a
      | [ffff80098b982c00] pgd=00000009ffff8803, pud=0000000000000000
      | Internal error: Oops: 96000045 [#1] PREEMPT SMP
      | Modules linked in:
      | CPU: 2 PID: 1561 Comm: kvm-vcpu-0 Not tainted 4.17.0-rc3-00001-ga912e2261ca6-dirty #1323
      | Hardware name: ARM Juno development board (r1) (DT)
      | pstate: 60000005 (nZCv daif -PAN -UAO)
      | pc : vcpu_write_sys_reg+0x50/0x134
      | lr : vcpu_write_sys_reg+0x50/0x134
      
      | Process kvm-vcpu-0 (pid: 1561, stack limit = 0x000000006df4728b)
      | Call trace:
      |  vcpu_write_sys_reg+0x50/0x134
      |  kvm_psci_vcpu_on+0x14c/0x150
      |  kvm_psci_0_2_call+0x244/0x2a4
      |  kvm_hvc_call_handler+0x1cc/0x258
      |  handle_hvc+0x20/0x3c
      |  handle_exit+0x130/0x1ec
      |  kvm_arch_vcpu_ioctl_run+0x340/0x614
      |  kvm_vcpu_ioctl+0x4d0/0x840
      |  do_vfs_ioctl+0xc8/0x8d0
      |  ksys_ioctl+0x78/0xa8
      |  sys_ioctl+0xc/0x18
      |  el0_svc_naked+0x30/0x34
      | Code: 73620291 604d00b0 00201891 1ab10194 (957a33f8)
      |---[ end trace 4b4a4f9628596602 ]---
      
      Fix the order of the arguments.
      
      Fixes: 8d404c4c ("KVM: arm64: Rewrite system register accessors to read/write functions")
      CC: Christoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      1975fa56
  9. 03 5月, 2018 4 次提交
    • H
      parisc: Fix section mismatches · 8d73b180
      Helge Deller 提交于
      Fix three section mismatches:
      1) Section mismatch in reference from the function ioread8() to the
         function .init.text:pcibios_init_bridge()
      2) Section mismatch in reference from the function free_initmem() to the
         function .init.text:map_pages()
      3) Section mismatch in reference from the function ccio_ioc_init() to
         the function .init.text:count_parisc_driver()
      Signed-off-by: NHelge Deller <deller@gmx.de>
      8d73b180
    • H
      parisc: drivers.c: Fix section mismatches · b819439f
      Helge Deller 提交于
      Fix two section mismatches in drivers.c:
      1) Section mismatch in reference from the function alloc_tree_node() to
         the function .init.text:create_tree_node().
      2) Section mismatch in reference from the function walk_native_bus() to
         the function .init.text:alloc_pa_dev().
      Signed-off-by: NHelge Deller <deller@gmx.de>
      b819439f
    • D
      bpf, x64: fix memleak when not converging on calls · 39f56ca9
      Daniel Borkmann 提交于
      The JIT logic in jit_subprogs() is as follows: for all subprogs we
      allocate a bpf_prog_alloc(), populate it (prog->is_func = 1 here),
      and pass it to bpf_int_jit_compile(). If a failure occurred during
      JIT and prog->jited is not set, then we bail out from attempting to
      JIT the whole program, and punt to the interpreter instead. In case
      JITing went successful, we fixup BPF call offsets and do another
      pass to bpf_int_jit_compile() (extra_pass is true at that point) to
      complete JITing calls. Given that requires to pass JIT context around
      addrs and jit_data from x86 JIT are freed in the extra_pass in
      bpf_int_jit_compile() when calls are involved (if not, they can
      be freed immediately). However, if in the original pass, the JIT
      image didn't converge then we leak addrs and jit_data since image
      itself is NULL, the prog->is_func is set and extra_pass is false
      in that case, meaning both will become unreachable and are never
      cleaned up, therefore we need to free as well on !image. Only x64
      JIT is affected.
      
      Fixes: 1c2a088a ("bpf: x64: add JIT support for multi-function programs")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      39f56ca9
    • D
      bpf, x64: fix memleak when not converging after image · 3aab8884
      Daniel Borkmann 提交于
      While reviewing x64 JIT code, I noticed that we leak the prior allocated
      JIT image in the case where proglen != oldproglen during the JIT passes.
      Prior to the commit e0ee9c12 ("x86: bpf_jit: fix two bugs in eBPF JIT
      compiler") we would just break out of the loop, and using the image as the
      JITed prog since it could only shrink in size anyway. After e0ee9c12,
      we would bail out to out_addrs label where we free addrs and jit_data but
      not the image coming from bpf_jit_binary_alloc().
      
      Fixes: e0ee9c12 ("x86: bpf_jit: fix two bugs in eBPF JIT compiler")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      3aab8884
  10. 02 5月, 2018 5 次提交
  11. 01 5月, 2018 3 次提交
  12. 28 4月, 2018 1 次提交
  13. 27 4月, 2018 4 次提交
    • J
      kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use · a468f2db
      Junaid Shahid 提交于
      Currently, KVM flushes the TLB after a change to the APIC access page
      address or the APIC mode when EPT mode is enabled. However, even in
      shadow paging mode, a TLB flush is needed if VPIDs are being used, as
      specified in the Intel SDM Section 29.4.5.
      
      So replace vmx_flush_tlb_ept_only() with vmx_flush_tlb(), which will
      flush if either EPT or VPIDs are in use.
      Signed-off-by: NJunaid Shahid <junaids@google.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      a468f2db
    • A
      x86/entry/64/compat: Preserve r8-r11 in int $0x80 · 8bb2610b
      Andy Lutomirski 提交于
      32-bit user code that uses int $80 doesn't care about r8-r11.  There is,
      however, some 64-bit user code that intentionally uses int $0x80 to invoke
      32-bit system calls.  From what I've seen, basically all such code assumes
      that r8-r15 are all preserved, but the kernel clobbers r8-r11.  Since I
      doubt that there's any code that depends on int $0x80 zeroing r8-r11,
      change the kernel to preserve them.
      
      I suspect that very little user code is broken by the old clobber, since
      r8-r11 are only rarely allocated by gcc, and they're clobbered by function
      calls, so they only way we'd see a problem is if the same function that
      invokes int $0x80 also spills something important to one of these
      registers.
      
      The current behavior seems to date back to the historical commit
      "[PATCH] x86-64 merge for 2.6.4".  Before that, all regs were
      preserved.  I can't find any explanation of why this change was made.
      
      Update the test_syscall_vdso_32 testcase as well to verify the new
      behavior, and it strengthens the test to make sure that the kernel doesn't
      accidentally permute r8..r15.
      Suggested-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Link: https://lkml.kernel.org/r/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.luto@kernel.org
      8bb2610b
    • A
      x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds · 1a512c08
      Arnd Bergmann 提交于
      A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout
      (as seen from user space)  a few years ago: Originally, __BITS_PER_LONG
      was defined as 64 on x32, so we did not have padding after the 64-bit
      __kernel_time_t fields, After __BITS_PER_LONG got changed to 32,
      applications would observe extra padding.
      
      In other parts of the uapi headers we seem to have a mix of those
      expecting either 32 or 64 on x32 applications, so we can't easily revert
      the path that broke these two structures.
      
      Instead, this patch decouples x32 from the other architectures and moves
      it back into arch specific headers, partially reverting the even older
      commit 73a2d096 ("x86: remove all now-duplicate header files").
      
      It's not clear whether this ever made any difference, since at least
      glibc carries its own (correct) copy of both of these header files,
      so possibly no application has ever observed the definitions here.
      
      Based on a suggestion from H.J. Lu, I tried out the tool from
      https://github.com/hjl-tools/linux-header to find other such
      bugs, which pointed out the same bug in statfs(), which also has
      a separate (correct) copy in glibc.
      
      Fixes: f4b4aae1 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: "H . J . Lu" <hjl.tools@gmail.com>
      Cc: Jeffrey Walton <noloader@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Link: https://lkml.kernel.org/r/20180424212013.3967461-1-arnd@arndb.de
      1a512c08
    • P
      x86/setup: Do not reserve a crash kernel region if booted on Xen PV · 3db3eb28
      Petr Tesarik 提交于
      Xen PV domains cannot shut down and start a crash kernel. Instead,
      the crashing kernel makes a SCHEDOP_shutdown hypercall with the
      reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
      arch/x86/xen/enlighten_pv.c.
      
      A crash kernel reservation is merely a waste of RAM in this case. It
      may also confuse users of kexec_load(2) and/or kexec_file_load(2).
      When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
      respectively, these syscalls return success, which is technically
      correct, but the crash kexec image will never be actually used.
      Signed-off-by: NPetr Tesarik <ptesarik@suse.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jean Delvare <jdelvare@suse.de>
      Link: https://lkml.kernel.org/r/20180425120835.23cef60c@ezekiel.suse.cz
      3db3eb28
反馈
建议
客服 返回
顶部