Skip to content
Snippets Groups Projects
  1. Jul 16, 2007
  2. May 11, 2007
  3. May 08, 2007
    • Prarit Bhargava's avatar
      Use stop_machine_run in the Intel RNG driver · ee527cd3
      Prarit Bhargava authored
      
      Replace call_smp_function with stop_machine_run in the Intel RNG driver.
      
      CPU A has done read_lock(&lock)
      CPU B has done write_lock_irq(&lock) and is waiting for A to release the lock.
      
      A third CPU calls call_smp_function and issues the IPI.  CPU A takes CPU
      C's IPI.  CPU B is waiting with interrupts disabled and does not see the
      IPI.  CPU C is stuck waiting for CPU B to respond to the IPI.
      
      Deadlock.
      
      The solution is to use stop_machine_run instead of call_smp_function
      (call_smp_function should not be called in situations where the CPUs may be
      suspended).
      
      [haruo.tomita@toshiba.co.jp: fix a typo in mod_init()]
      [haruo.tomita@toshiba.co.jp: fix memory leak]
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: "Tomita, Haruo" <haruo.tomita@toshiba.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ee527cd3
  4. Sep 29, 2006
  5. Aug 27, 2006
  6. Jul 03, 2006
  7. Jun 25, 2006
  8. Jan 10, 2006
  9. Nov 13, 2005
    • Kirill Korotaev's avatar
      [PATCH] stop_machine() vs. synchronous IPI send deadlock · 4557398f
      Kirill Korotaev authored
      
      This fixes deadlock of stop_machine() vs.  synchronous IPI send.  The
      problem is that stop_machine() disables interrupts before disabling
      preemption on other CPUs.  So if another CPU is preempted and then calls
      something like flush_tlb_all() it will deadlock with CPU doing
      stop_machine() and which can't process IPI due to disabled IRQs.
      
      I changed stop_machine() to do the same things exactly as it does on other
      CPUs, i.e.  it should disable preemption first on _all_ CPUs including
      itself and only after that disable IRQs.
      
      Signed-off-by: default avatarKirill Korotaev <dev@sw.ru>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Andrey Savochkin" <saw@sawoct.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4557398f
  10. Jun 21, 2005
    • Ingo Molnar's avatar
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar authored
      
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      39c715b7
  11. May 01, 2005
  12. Apr 16, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
Loading