1. 16 6月, 2011 11 次提交
  2. 15 6月, 2011 1 次提交
  3. 14 6月, 2011 10 次提交
  4. 12 6月, 2011 1 次提交
  5. 10 6月, 2011 4 次提交
  6. 09 6月, 2011 8 次提交
  7. 08 6月, 2011 5 次提交
    • T
      x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU · fd8a7de1
      Thomas Gleixner 提交于
      After a newly plugged CPU sets the cpu_online bit it enables
      interrupts and goes idle. The cpu which brought up the new cpu waits
      for the cpu_online bit and when it observes it, it sets the cpu_active
      bit for this cpu. The cpu_active bit is the relevant one for the
      scheduler to consider the cpu as a viable target.
      
      With forced threaded interrupt handlers which imply forced threaded
      softirqs we observed the following race:
      
      cpu 0                         cpu 1
      
      bringup(cpu1);
                                    set_cpu_online(smp_processor_id(), true);
      		              local_irq_enable();
      while (!cpu_online(cpu1));
                                    timer_interrupt()
                                      -> wake_up(softirq_thread_cpu1);
                                           -> enqueue_on(softirq_thread_cpu1, cpu0);
      
                                                                              ^^^^
      
      cpu_notify(CPU_ONLINE, cpu1);
        -> sched_cpu_active(cpu1)
           -> set_cpu_active((cpu1, true);
      
      When an interrupt happens before the cpu_active bit is set by the cpu
      which brought up the newly onlined cpu, then the scheduler refuses to
      enqueue the woken thread which is bound to that newly onlined cpu on
      that newly onlined cpu due to the not yet set cpu_active bit and
      selects a fallback runqueue. Not really an expected and desirable
      behaviour.
      
      So far this has only been observed with forced hard/softirq threading,
      but in theory this could happen without forced threaded hard/softirqs
      as well. It's probably unobservable as it would take a massive
      interrupt storm on the newly onlined cpu which causes the softirq loop
      to wake up the softirq thread and an even longer delay of the cpu
      which waits for the cpu_online bit.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: stable@kernel.org # 2.6.39
      fd8a7de1
    • D
      MN10300: Add missing _sdata declaration · 40182373
      David Howells 提交于
      _sdata needs to be declared in the linker script now as of commit
      a2d063ac ("extable, core_kernel_data(): Make sure all archs define
      _sdata")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      40182373
    • D
      MN10300: die_if_no_fixup() shouldn't use get_user() as it doesn't call set_fs() · db1c9dfa
      David Howells 提交于
      die_if_no_fixup() shouldn't use get_user() as it doesn't call set_fs() to
      indicate that it wants to probe a kernel address.  Instead it should use
      probe_kernel_read().
      
      This fixes the problem of gdb seeing SIGILL rather than SIGTRAP when hitting
      the KGDB special breakpoint upon SysRq+g being seen.  The problem was that
      die_if_no_fixup() was failing to read the opcode of the instruction that caused
      the exception, and thus not fixing up the exception.
      
      This caused gdb to get a S04 response to the $? request in its remote protocol
      rather than S05 - which would then cause it to continue with $C04 rather than
      $c in an attempt to pass the signal onto the inferior process.  The kernel,
      however, does not support $Cnn, and so objects by returning an E22 response,
      indicating an error.  gdb does not expect this and prints:
      
      	warning: Remote failure reply: E22
      
      and then returns to the gdb command prompt unable to continue.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      db1c9dfa
    • D
      MN10300: Fix one of the kernel debugger cacheflush variants · 2e65d1f6
      David Howells 提交于
      One of the kernel debugger cacheflush variants escaped proper testing.  Two of
      the labels are wrong, being derived from the code that was copied to construct
      the variant.
      
      The first label results in the following assembler message:
      
          AS      arch/mn10300/mm/cache-dbg-flush-by-reg.o
        arch/mn10300/mm/cache-dbg-flush-by-reg.S: Assembler messages:
        arch/mn10300/mm/cache-dbg-flush-by-reg.S:123: Error: symbol `debugger_local_cache_flushinv_no_dcache' is already defined
      
      And the second label results in the following linker message:
      
        arch/mn10300/mm/built-in.o:(.text+0x1d39): undefined reference to `mn10300_local_icache_inv_range_reg_end'
        arch/mn10300/mm/built-in.o:(.text+0x1d39): relocation truncated to fit: R_MN10300_PCREL16 against undefined symbol `mn10300_local_icache_inv_range_reg_end'
      
      To test this file the following configuration pieces must be set:
      
      	CONFIG_AM34=y
      	CONFIG_MN10300_CACHE_WBACK=y
      	CONFIG_MN10300_DEBUGGER_CACHE_FLUSH_BY_REG=y
      	CONFIG_MN10300_CACHE_MANAGE_BY_REG=y
      	CONFIG_AM34_HAS_CACHE_SNOOP=n
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e65d1f6
    • J
      sparc: Remove unnecessary semicolons · 6cb79b3f
      Joe Perches 提交于
      Semicolons are not necessary after switch/while/for/if braces
      so remove them.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cb79b3f