1. 16 3月, 2015 5 次提交
  2. 06 3月, 2015 2 次提交
  3. 05 3月, 2015 1 次提交
  4. 04 3月, 2015 1 次提交
  5. 03 3月, 2015 1 次提交
    • R
      KVM: SVM: fix interrupt injection (apic->isr_count always 0) · f563db4b
      Radim Krčmář 提交于
      In commit b4eef9b3, we started to use hwapic_isr_update() != NULL
      instead of kvm_apic_vid_enabled(vcpu->kvm).  This didn't work because
      SVM had it defined and "apicv" path in apic_{set,clear}_isr() does not
      change apic->isr_count, because it should always be 1.  The initial
      value of apic->isr_count was based on kvm_apic_vid_enabled(vcpu->kvm),
      which is always 0 for SVM, so KVM could have injected interrupts when it
      shouldn't.
      
      Fix it by implicitly setting SVM's hwapic_isr_update to NULL and make the
      initial isr_count depend on hwapic_isr_update() for good measure.
      
      Fixes: b4eef9b3 ("kvm: x86: vmx: NULL out hwapic_isr_update() in case of !enable_apicv")
      Reported-and-tested-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      f563db4b
  6. 28 2月, 2015 1 次提交
  7. 27 2月, 2015 1 次提交
  8. 24 2月, 2015 6 次提交
  9. 22 2月, 2015 1 次提交
  10. 21 2月, 2015 2 次提交
    • P
      kprobes/x86: Check for invalid ftrace location in __recover_probed_insn() · 2a6730c8
      Petr Mladek 提交于
      __recover_probed_insn() should always be called from an address
      where an instructions starts. The check for ftrace_location()
      might help to discover a potential inconsistency.
      
      This patch adds WARN_ON() when the inconsistency is detected.
      Also it adds handling of the situation when the original code
      can not get recovered.
      Suggested-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Ananth NMavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1424441250-27146-3-git-send-email-pmladek@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2a6730c8
    • P
      kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace · 650b7b23
      Petr Mladek 提交于
      can_probe() checks if the given address points to the beginning
      of an instruction. It analyzes all the instructions from the
      beginning of the function until the given address. The code
      might be modified by another Kprobe. In this case, the current
      code is read into a buffer, int3 breakpoint is replaced by the
      saved opcode in the buffer, and can_probe() analyzes the buffer
      instead.
      
      There is a bug that __recover_probed_insn() tries to restore
      the original code even for Kprobes using the ftrace framework.
      But in this case, the opcode is not stored. See the difference
      between arch_prepare_kprobe() and arch_prepare_kprobe_ftrace().
      The opcode is stored by arch_copy_kprobe() only from
      arch_prepare_kprobe().
      
      This patch makes Kprobe to use the ideal 5-byte NOP when the
      code can be modified by ftrace. It is the original instruction,
      see ftrace_make_nop() and ftrace_nop_replace().
      
      Note that we always need to use the NOP for ftrace locations.
      Kprobes do not block ftrace and the instruction might get
      modified at anytime. It might even be in an inconsistent state
      because it is modified step by step using the int3 breakpoint.
      
      The patch also fixes indentation of the touched comment.
      
      Note that I found this problem when playing with Kprobes. I did
      it on x86_64 with gcc-4.8.3 that supported -mfentry. I modified
      samples/kprobes/kprobe_example.c and added offset 5 to put
      the probe right after the fentry area:
      
       static struct kprobe kp = {
       	.symbol_name	= "do_fork",
      +	.offset = 5,
       };
      
      Then I was able to load kprobe_example before jprobe_example
      but not the other way around:
      
        $> modprobe jprobe_example
        $> modprobe kprobe_example
        modprobe: ERROR: could not insert 'kprobe_example': Invalid or incomplete multibyte or wide character
      
      It did not make much sense and debugging pointed to the bug
      described above.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth NMavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1424441250-27146-2-git-send-email-pmladek@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      650b7b23
  11. 20 2月, 2015 2 次提交
  12. 19 2月, 2015 16 次提交
  13. 18 2月, 2015 1 次提交
    • J
      x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable() · d97eb896
      Joerg Roedel 提交于
      When an interrupt is migrated away from a cpu it will stay
      in its vector_irq array until smp_irq_move_cleanup_interrupt
      succeeded. The cfg->move_in_progress flag is cleared already
      when the IPI was sent.
      
      When the interrupt is destroyed after migration its 'struct
      irq_desc' is freed and the vector_irq arrays are cleaned up.
      But since cfg->move_in_progress is already 0 the references
      at cpus before the last migration will not be cleared. So
      this would leave a reference to an already destroyed irq
      alive.
      
      When the cpu is taken down at this point, the
      check_irq_vectors_for_cpu_disable() function finds a valid irq
      number in the vector_irq array, but gets NULL for its
      descriptor and dereferences it, causing a kernel panic.
      
      This has been observed on real systems at shutdown. Add a
      check to check_irq_vectors_for_cpu_disable() for a valid
      'struct irq_desc' to prevent this issue.
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: alnovak@suse.com
      Cc: joro@8bytes.org
      Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d97eb896