1. 12 Nov, 2010 1 commit
    • Frederic Weisbecker's avatar
      x86: Ignore trap bits on single step exceptions · 6c0aca28
      Frederic Weisbecker authored
      When a single step exception fires, the trap bits, used to
      signal hardware breakpoints, are in a random state.
      
      These trap bits might be set if another exception will follow,
      like a breakpoint in the next instruction, or a watchpoint in the
      previous one. Or there can be any junk there.
      
      So if we handle these trap bits during the single step exception,
      we are going to handle an exception twice, or we are going to
      handle junk.
      
      Just ignore them in this case.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332Reported-by: default avatarMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: All since 2.6.33.x <stable@kernel.org>
      6c0aca28
  2. 30 Oct, 2010 1 commit
  3. 29 Oct, 2010 7 commits
    • Steven Rostedt's avatar
      jump label: Add work around to i386 gcc asm goto bug · 45f81b1c
      Steven Rostedt authored
      On i386 (not x86_64) early implementations of gcc would have a bug
      with asm goto causing it to produce code like the following:
      
      (This was noticed by Peter Zijlstra)
      
         56 pushl 0
         67 nopl         jmp 0x6f
            popl
            jmp 0x8c
      
         6f              mov
                         test
                         je 0x8c
      
         8c mov
            call *(%esp)
      
      The jump added in the asm goto skipped over the popl that matched
      the pushl 0, which lead up to a quick crash of the system when
      the jump was enabled. The nopl is defined in the asm goto () statement
      and when tracepoints are enabled, the nop changes to a jump to the label
      that was specified by the asm goto. asm goto is suppose to tell gcc that
      the code in the asm might jump to an external label. Here gcc obviously
      fails to make that work.
      
      The bug report for gcc is here:
      
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226
      
      The bug only appears on x86 when not compiled with
      -maccumulate-outgoing-args. This option is always set on x86_64 and it
      is also the work around for a function graph tracer i386 bug.
      (See commit: 746357d6)
      This explains why the bug only showed up on i386 when function graph
      tracer was not enabled.
      
      This patch now adds a CONFIG_JUMP_LABEL option that is default
      off instead of using jump labels by default. When jump labels are
      enabled, the -maccumulate-outgoing-args will be used (causing a
      slightly larger kernel image on i386). This option will exist
      until we have a way to detect if the gcc compiler in use is safe
      to use on all configurations without the work around.
      
      Note, there exists such a test, but for now we will keep the enabling
      of jump label as a manual option.
      
      Archs that know the compiler is safe with asm goto, may choose to
      select JUMP_LABEL and enable it by default.
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Cause-discovered-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Richard Henderson <rth@redhat.com>
      LKML-Reference: <1288028746.3673.11.camel@laptop>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      45f81b1c
    • H. Peter Anvin's avatar
      x86, ftrace: Use safe noops, drop trap test · 2d1d7126
      H. Peter Anvin authored
      Always use a safe 5-byte noop sequence.  Drop the trap test, since it
      is known to return false negatives on some virtualization platforms on
      32 bits.  The resulting code is both simpler and safer.
      
      Cc: Daniel Drake <dsd@laptop.org>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      2d1d7126
    • David Miller's avatar
      jump_label: Fix unaligned traps on sparc. · f0daed02
      David Miller authored
      The vmlinux.lds.h knobs to emit the __jump_table section in the main
      kernel image takes care to align the section, but this doesn't help
      for the __jump_table section that gets emitted into modules.
      
      Fix the resulting lack of section alignment by explicitly specifying
      it in the assembler.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      LKML-Reference: <20101023.110624.226758370.davem@davemloft.net>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f0daed02
    • Steven Rostedt's avatar
      jump label: Make arch_jump_label_text_poke_early() optional · 95bcd683
      Steven Rostedt authored
      Some archs do not need to do anything special for jump labels on
      startup (like MIPS).  This patch adds a weak function stub for
      arch_jump_label_text_poke_early();
      
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <1286218615-24011-2-git-send-email-ddaney@caviumnetworks.com>
      LKML-Reference: <20101015201037.703989993@goodmis.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      95bcd683
    • Steven Rostedt's avatar
      jump label: Fix error with preempt disable holding mutex · de31c3ca
      Steven Rostedt authored
      Kprobes and jump label were having a race between mutexes that
      was fixed by reordering the jump label. But this reordering
      moved the jump label mutex into a preempt disable location.
      
      This patch does a little fiddling to move the grabbing of
      the jump label mutex from inside the preempt disable section
      and still keep the order correct between the mutex and the
      kprobes lock.
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      de31c3ca
    • Tejun Heo's avatar
      oprofile: Remove deprecated use of flush_scheduled_work() · 3d7851b3
      Tejun Heo authored
      flush_scheduled_work() is deprecated and scheduled to be removed.
      sync_stop() currently cancels cpu_buffer works inside buffer_mutex and
      flushes the system workqueue outside.  Instead, split end_cpu_work()
      into two parts - stopping further work enqueues and flushing works -
      and do the former inside buffer_mutex and latter outside.
      
      For stable kernels v2.6.35.y and v2.6.36.y.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      3d7851b3
    • Santosh Shilimkar's avatar
      oprofile: Fix the hang while taking the cpu offline · 4ac3dbec
      Santosh Shilimkar authored
      The kernel build with CONFIG_OPROFILE and CPU_HOTPLUG enabled.
      The oprofile is initialised using system timer in absence of hardware
      counters supports. Oprofile isn't started from userland.
      
      In this setup while doing a CPU offline the kernel hangs in infinite
      for loop inside lock_hrtimer_base() function
      
      This happens because as part of oprofile_cpu_notify(, it tries to
      stop an hrtimer which was never started. These per-cpu hrtimers
      are started when the oprfile is started.
      	echo 1	> /dev/oprofile/enable
      
      This problem also existwhen the cpu is booted with maxcpus parameter
      set. When bringing the remaining cpus online the timers are started
      even if oprofile is not yet enabled.
      
      This patch fix this issue by adding a state variable so that
      these hrtimer start/stop is only attempted when oprofile is
      started
      
      For stable kernels v2.6.35.y and v2.6.36.y.
      Reported-by: default avatarJan Sebastien <s-jan@ti.com>
      Tested-by: default avatarsricharan <r.sricharan@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      4ac3dbec
  4. 28 Oct, 2010 31 commits