1. 13 3月, 2009 3 次提交
  2. 12 3月, 2009 3 次提交
  3. 11 3月, 2009 13 次提交
  4. 10 3月, 2009 4 次提交
  5. 09 3月, 2009 7 次提交
    • R
      lguest: fix for CONFIG_SPARSE_IRQ=y · 6db6a5f3
      Rusty Russell 提交于
      Impact: remove lots of lguest boot WARN_ON() when CONFIG_SPARSE_IRQ=y
      
      We now need to call irq_to_desc_alloc_cpu() before
      set_irq_chip_and_handler_name(), but we can't do that from init_IRQ (no
      kmalloc available).
      
      So do it as we use interrupts instead.  Also means we only alloc for
      irqs we use, which was the intent of CONFIG_SPARSE_IRQ anyway.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@redhat.com>
      6db6a5f3
    • R
      lguest: fix crash 'unhandled trap 13 at <native_read_msr_safe>' · cbd88c8e
      Rusty Russell 提交于
      Impact: fix lguest boot crash on modern Intel machines
      
      The code in early_init_intel does:
      
      	if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
      		u64 misc_enable;
      
      		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
      
      And that rdmsr faults (not allowed from non-0 PL).  We can get around
      this by mugging the family ID part of the cpuid.  5 seems like a good
      number.
      
      Of course, this is a hack (how very lguest!).  We could just indicate
      that we don't support MSRs, or implement lguest_rdmst.
      Reported-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Tested-by: NPatrick McHardy <kaber@trash.net>
      cbd88c8e
    • J
      x86-32: make sure virt_addr_valid() returns false for fixmap addresses · 0feca851
      Jeremy Fitzhardinge 提交于
      I found that virt_addr_valid() was returning true for fixmap addresses.
      
      I'm not sure whether pfn_valid() is supposed to include this test,
      but there's no harm in being explicit.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B166D6.2080505@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0feca851
    • S
      x86 mmiotrace: fix remove_kmmio_fault_pages() · d0fc63f7
      Stuart Bennett 提交于
      Impact: fix race+crash in mmiotrace
      
      The list manipulation in remove_kmmio_fault_pages() was broken. If more
      than one consecutive kmmio_fault_page was re-added during the grace
      period between unregister_kmmio_probe() and remove_kmmio_fault_pages(),
      the list manipulation failed to remove pages from the release list.
      
      After a second grace period the pages get into rcu_free_kmmio_fault_pages()
      and raise a BUG_ON() kernel crash.
      
      The list manipulation is fixed to properly remove pages from the release
      list.
      
      This bug has been present from the very beginning of mmiotrace in the
      mainline kernel. It was introduced in 0fd0e3da ("x86: mmiotrace full
      patch, preview 1");
      
      An urgent fix for Linus. Tested by Stuart (on 32-bit) and Pekka
      (on amd and intel 64-bit systems, nouveau and nvidia proprietary).
      Signed-off-by: NStuart Bennett <stuart@freedesktop.org>
      Signed-off-by: NPekka Paalanen <pq@iki.fi>
      LKML-Reference: <20090308202135.34933feb@daedalus.pq.iki.fi>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d0fc63f7
    • Y
      x86: fix warning about nodeid · e954ef20
      Yinghai Lu 提交于
      Impact: cleanup
      
      Ingo found there warning about nodeid with some configs.
      
      try to use for_each_online_node for non numa too. in that case
      nodeid will be 0.
      
      also move out boundary checking from setup_node_bootmem(), so
      non-numa config will not check it.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <49B03069.80001@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e954ef20
    • R
      MIPS: compat: Implement is_compat_task. · 4302e5d5
      Ralf Baechle 提交于
      This is a build fix required after "x86-64: seccomp: fix 32/64 syscall
      hole" (commit 5b101740).  MIPS doesn't
      have the issue that was fixed for x86-64 by that patch.
      
      This also doesn't solve the N32 issue which is that N32 seccomp processes
      will be treated as non-compat processes thus only have access to N64
      syscalls.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4302e5d5
    • W
      x86: don't define __this_fixmap_does_not_exist() · 8827247f
      Wang Chen 提交于
      Impact: improve out-of-range fixmap index debugging
      
      Commit "1b42f516"
      defined the __this_fixmap_does_not_exist() function
      with a WARN_ON(1) in it.
      
      This causes the linker to not report an error when
      __this_fixmap_does_not_exist() is called with a
      non-constant parameter.
      
      Ingo defined __this_fixmap_does_not_exist() because he
      wanted to get virt addresses of fix memory of nest level
      by non-constant index.
      
      But we can fix this and still keep the link-time check:
      
      We can get the four slot virt addresses on link time and
      store them to array slot_virt[].
      
      Then we can then refer the slot_virt with non-constant index,
      in the ioremap-leak detection code.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      LKML-Reference: <49B2075B.4070509@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8827247f
  6. 08 3月, 2009 2 次提交
    • Y
      x86: remove smp_apply_quirks()/smp_checks() · 1f442d70
      Yinghai Lu 提交于
      Impact: cleanup and code size reduction on 64-bit
      
      This code is only applied to Intel Pentium and AMD K7 32-bit cpus.
      
      Move those checks to intel_init()/amd_init() for 32-bit
      so 64-bit will not build this code.
      
      Also change to use cpu_index check to see if we need to emit warning.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B377D2.8030108@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1f442d70
    • C
      x86: UV: remove uv_flush_tlb_others() WARN_ON · 3a450de1
      Cliff Wickman 提交于
      In uv_flush_tlb_others() (arch/x86/kernel/tlb_uv.c),
      the "WARN_ON(!in_atomic())" fails if CONFIG_PREEMPT is not enabled.
      
      And CONFIG_PREEMPT is not enabled by default in the distribution that
      most UV owners will use.
      
      We could #ifdef CONFIG_PREEMPT the warning, but that is not good form.
      And there seems to be no suitable fix to in_atomic() when CONFIG_PREMPT
      is not on.
      
      As Ingo commented:
      
        > and we have no proper primitive to test for atomicity. (mainly
        > because we dont know about atomicity on a non-preempt kernel)
      
      So we drop the WARN_ON.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a450de1
  7. 07 3月, 2009 2 次提交
  8. 06 3月, 2009 6 次提交