1. 28 1月, 2015 4 次提交
  2. 20 1月, 2015 1 次提交
  3. 16 1月, 2015 2 次提交
  4. 09 1月, 2015 1 次提交
  5. 23 12月, 2014 2 次提交
  6. 11 12月, 2014 1 次提交
    • J
      perf/x86/intel/uncore: Make sure only uncore events are collected · af91568e
      Jiri Olsa 提交于
      The uncore_collect_events functions assumes that event group
      might contain only uncore events which is wrong, because it
      might contain any type of events.
      
      This bug leads to uncore framework touching 'not' uncore events,
      which could end up all sorts of bugs.
      
      One was triggered by Vince's perf fuzzer, when the uncore code
      touched breakpoint event private event space as if it was uncore
      event and caused BUG:
      
         BUG: unable to handle kernel paging request at ffffffff82822068
         IP: [<ffffffff81020338>] uncore_assign_events+0x188/0x250
         ...
      
      The code in uncore_assign_events() function was looking for
      event->hw.idx data while the event was initialized as a
      breakpoint with different members in event->hw union.
      
      This patch forces uncore_collect_events() to collect only uncore
      events.
      Reported-by: NVince Weaver <vince@deater.net>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jolsa@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      af91568e
  7. 10 12月, 2014 1 次提交
  8. 08 12月, 2014 2 次提交
  9. 06 12月, 2014 3 次提交
  10. 01 12月, 2014 2 次提交
  11. 20 11月, 2014 2 次提交
    • C
      x86, mce: Support memory error recovery for both UCNA and Deferred error in machine_check_poll · fa92c586
      Chen Yucong 提交于
      Uncorrected no action required (UCNA) - is a uncorrected recoverable
      machine check error that is not signaled via a machine check exception
      and, instead, is reported to system software as a corrected machine
      check error. UCNA errors indicate that some data in the system is
      corrupted, but the data has not been consumed and the processor state
      is valid and you may continue execution on this processor. UCNA errors
      require no action from system software to continue execution. Note that
      UCNA errors are supported by the processor only when IA32_MCG_CAP[24]
      (MCG_SER_P) is set.
                                                     -- Intel SDM Volume 3B
      
      Deferred errors are errors that cannot be corrected by hardware, but
      do not cause an immediate interruption in program flow, loss of data
      integrity, or corruption of processor state. These errors indicate
      that data has been corrupted but not consumed. Hardware writes information
      to the status and address registers in the corresponding bank that
      identifies the source of the error if deferred errors are enabled for
      logging. Deferred errors are not reported via machine check exceptions;
      they can be seen by polling the MCi_STATUS registers.
                                                      -- AMD64 APM Volume 2
      
      Above two items, both UCNA and Deferred errors belong to detected
      errors, but they can't be corrected by hardware, and this is very
      similar to Software Recoverable Action Optional (SRAO) errors.
      Therefore, we can take some actions that have been used for handling
      SRAO errors to handle UCNA and Deferred errors.
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NChen Yucong <slaoub@gmail.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      fa92c586
    • C
      x86, mce, severity: Extend the the mce_severity mechanism to handle UCNA/DEFERRED error · e3480271
      Chen Yucong 提交于
      Until now, the mce_severity mechanism can only identify the severity
      of UCNA error as MCE_KEEP_SEVERITY. Meanwhile, it is not able to filter
      out DEFERRED error for AMD platform.
      
      This patch extends the mce_severity mechanism for handling
      UCNA/DEFERRED error. In order to do this, the patch introduces a new
      severity level - MCE_UCNA/DEFERRED_SEVERITY.
      
      In addition, mce_severity is specific to machine check exception,
      and it will check MCIP/EIPV/RIPV bits. In order to use mce_severity
      mechanism in non-exception context, the patch also introduces a new
      argument (is_excp) for mce_severity. `is_excp' is used to explicitly
      specify the calling context of mce_severity.
      Reviewed-by: NAravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
      Signed-off-by: NChen Yucong <slaoub@gmail.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e3480271
  12. 19 11月, 2014 1 次提交
  13. 18 11月, 2014 1 次提交
    • D
      x86: Remove arbitrary instruction size limit in instruction decoder · 6ba48ff4
      Dave Hansen 提交于
      The current x86 instruction decoder steps along through the
      instruction stream but always ensures that it never steps farther
      than the largest possible instruction size (MAX_INSN_SIZE).
      
      The MPX code is now going to be doing some decoding of userspace
      instructions.  We copy those from userspace in to the kernel and
      they're obviously completely untrusted coming from userspace.  In
      addition to the constraint that instructions can only be so long,
      we also have to be aware of how long the buffer is that came in
      from userspace.  This _looks_ to be similar to what the perf and
      kprobes is doing, but it's unclear to me whether they are
      affected.
      
      The whole reason we need this is that it is perfectly valid to be
      executing an instruction within MAX_INSN_SIZE bytes of an
      unreadable page. We should be able to gracefully handle short
      reads in those cases.
      
      This adds support to the decoder to record how long the buffer
      being decoded is and to refuse to "validate" the instruction if
      we would have gone over the end of the buffer to decode it.
      
      The kprobes code probably needs to be looked at here a bit more
      carefully.  This patch still respects the MAX_INSN_SIZE limit
      there but the kprobes code does look like it might be able to
      be a bit more strict than it currently is.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: NJim Keniston <jkenisto@us.ibm.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: x86@kernel.org
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20141114153957.E6B01535@viggo.jf.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      6ba48ff4
  14. 16 11月, 2014 8 次提交
  15. 12 11月, 2014 3 次提交
  16. 10 11月, 2014 1 次提交
  17. 08 11月, 2014 1 次提交
  18. 06 11月, 2014 1 次提交
  19. 03 11月, 2014 1 次提交
  20. 02 11月, 2014 1 次提交
    • B
      x86, microcode, AMD: Fix early ucode loading on 32-bit · 4750a0d1
      Borislav Petkov 提交于
      Konrad triggered the following splat below in a 32-bit guest on an AMD
      box. As it turns out, in save_microcode_in_initrd_amd() we're using the
      *physical* address of the container *after* we have enabled paging and
      thus we #PF in load_microcode_amd() when trying to access the microcode
      container in the ramdisk range.
      
      Because the ramdisk is exactly there:
      
      [    0.000000] RAMDISK: [mem 0x35e04000-0x36ef9fff]
      
      and we fault at 0x35e04304.
      
      And since this guest doesn't relocate the ramdisk, we don't do the
      computation which will give us the correct virtual address and we end up
      with the PA.
      
      So, we should actually be using virtual addresses on 32-bit too by the
      time we're freeing the initrd. Do that then!
      
      Unpacking initramfs...
      BUG: unable to handle kernel paging request at 35d4e304
      IP: [<c042e905>] load_microcode_amd+0x25/0x4a0
      *pde = 00000000
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.1-302.fc21.i686 #1
      Hardware name: Xen HVM domU, BIOS 4.4.1 10/01/2014
      task: f5098000 ti: f50d0000 task.ti: f50d0000
      EIP: 0060:[<c042e905>] EFLAGS: 00010246 CPU: 0
      EIP is at load_microcode_amd+0x25/0x4a0
      EAX: 00000000 EBX: f6e9ec4c ECX: 00001ec4 EDX: 00000000
      ESI: f5d4e000 EDI: 35d4e2fc EBP: f50d1ed0 ESP: f50d1e94
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 35d4e304 CR3: 00e33000 CR4: 000406d0
      Stack:
       00000000 00000000 f50d1ebc f50d1ec4 f5d4e000 c0d7735a f50d1ed0 15a3d17f
       f50d1ec4 00600f20 00001ec4 bfb83203 f6e9ec4c f5d4e000 c0d7735a f50d1ed8
       c0d80861 f50d1ee0 c0d80429 f50d1ef0 c0d889a9 f5d4e000 c0000000 f50d1f04
      Call Trace:
      ? unpack_to_rootfs
      ? unpack_to_rootfs
      save_microcode_in_initrd_amd
      save_microcode_in_initrd
      free_initrd_mem
      populate_rootfs
      ? unpack_to_rootfs
      do_one_initcall
      ? unpack_to_rootfs
      ? repair_env_string
      ? proc_mkdir
      kernel_init_freeable
      kernel_init
      ret_from_kernel_thread
      ? rest_init
      Reported-and-tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      References: https://bugzilla.redhat.com/show_bug.cgi?id=1158204
      Fixes: 75a1ba5b ("x86, microcode, AMD: Unify valid container checks")
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org> # v3.14+
      Link: http://lkml.kernel.org/r/20141101100100.GA4462@pd.tnicSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      4750a0d1
  21. 01 11月, 2014 1 次提交