1. 04 Mar, 2010 1 commit
    • Linus Torvalds's avatar
      Prioritize synchronous signals over 'normal' signals · a27341cd
      Linus Torvalds authored
      This makes sure that we pick the synchronous signals caused by a
      processor fault over any pending regular asynchronous signals sent to
      use by [t]kill().
      
      This is not strictly required semantics, but it makes it _much_ easier
      for programs like Wine that expect to find the fault information in the
      signal stack.
      
      Without this, if a non-synchronous signal gets picked first, the delayed
      asynchronous signal will have its signal context pointing to the new
      signal invocation, rather than the instruction that caused the SIGSEGV
      or SIGBUS in the first place.
      
      This is not all that pretty, and we're discussing making the synchronous
      signals more explicit rather than have these kinds of implicit
      preferences of SIGSEGV and friends.  See for example
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=15395
      
      for some of the discussion.  But in the meantime this is a simple and
      fairly straightforward work-around, and the whole
      
      	if (x & Y)
      		x &= Y;
      
      thing can be compiled into (and gcc does do it) just three instructions:
      
      	movq    %rdx, %rax
      	andl    $Y, %eax
      	cmovne  %rax, %rdx
      
      so it is at least a simple solution to a subtle issue.
      Reported-and-tested-by: default avatarPavel Vilim <wylda@volny.cz>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a27341cd
  2. 03 Mar, 2010 3 commits
  3. 02 Mar, 2010 2 commits
  4. 01 Mar, 2010 2 commits
    • Wu Fengguang's avatar
      resource: Fix generic page_is_ram() for partial RAM pages · 37b99dd5
      Wu Fengguang authored
      The System RAM walk shall skip partial RAM pages and avoid calling
      func() on them. So that page_is_ram() return 0 for a partial RAM page.
      
      In particular, it shall not call func() with len=0.
      This fixes a boot time bug reported by Sachin and root caused by Thomas:
      
      > >>> WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x169/0x2f1()
      > >>> Hardware name: BladeCenter LS21 -[79716AA]-
      > >>> Modules linked in:
      > >>> Pid: 0, comm: swapper Not tainted 2.6.33-git6-autotest #1
      > >>> Call Trace:
      > >>> [<ffffffff81047cff>] ? __ioremap_caller+0x169/0x2f1
      > >>> [<ffffffff81063b7d>] warn_slowpath_common+0x77/0xa4
      > >>> [<ffffffff81063bb9>] warn_slowpath_null+0xf/0x11
      > >>> [<ffffffff81047cff>] __ioremap_caller+0x169/0x2f1
      > >>> [<ffffffff813747a3>] ? acpi_os_map_memory+0x12/0x1b
      > >>> [<ffffffff81047f10>] ioremap_nocache+0x12/0x14
      > >>> [<ffffffff813747a3>] acpi_os_map_memory+0x12/0x1b
      > >>> [<ffffffff81282fa0>] acpi_tb_verify_table+0x29/0x5b
      > >>> [<ffffffff812827f0>] acpi_load_tables+0x39/0x15a
      > >>> [<ffffffff8191c8f8>] acpi_early_init+0x60/0xf5
      > >>> [<ffffffff818f2cad>] start_kernel+0x397/0x3a7
      > >>> [<ffffffff818f2295>] x86_64_start_reservations+0xa5/0xa9
      > >>> [<ffffffff818f237a>] x86_64_start_kernel+0xe1/0xe8
      > >>> ---[ end trace 4eaa2a86a8e2da22 ]---
      > >>> ioremap reserve_memtype failed -22
      
      The return code is -EINVAL, so it failed in the is_ram check, which is
      not too surprising
      
      > BIOS-provided physical RAM map:
      >  BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
      >  BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
      >  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
      >  BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable)
      >  BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data)
      
      The ACPI data is not starting on a page boundary and neither does the
      usable RAM area end on a page boundary. Very useful !
      
      > ACPI: DSDT 00000000cffa3900 036CE (v01 IBM    SERLEWIS 00001000 INTL 20060912)
      
      ACPI is trying to map DSDT at cffa3900, which results in a check
      vs. cffa3000 which is the relevant page boundary. The generic is_ram
      check correctly identifies that as RAM because it's in the usable
      resource area. The old e820 based is_ram check does not take
      overlapping resource areas into account. That's why it works.
      
      CC: Sachin Sant <sachinp@in.ibm.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      LKML-Reference: <20100301135551.GA9998@localhost>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      37b99dd5
    • David S. Miller's avatar
      sparc: Support show_unhandled_signals. · 4b177647
      David S. Miller authored
      Just faults right now, will add other traps later.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b177647
  5. 28 Feb, 2010 1 commit
  6. 27 Feb, 2010 3 commits
    • Paul E. McKenney's avatar
      rcu: Fix accelerated GPs for last non-dynticked CPU · 71da8132
      Paul E. McKenney authored
      This patch disables irqs across the call to rcu_needs_cpu().  It
      also enforces a hold-off period so that the idle loop doesn't
      softirq itself to death when there are lots of RCU callbacks in
      flight on the last non-dynticked CPU.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1267231138-27856-3-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      71da8132
    • Paul E. McKenney's avatar
      rcu: Fix accelerated grace periods for last non-dynticked CPU · a47cd880
      Paul E. McKenney authored
      It is invalid to invoke __rcu_process_callbacks() with irqs
      disabled, so do it indirectly via raise_softirq().  This
      requires a state-machine implementation to cycle through the
      grace-period machinery the required number of times.
      Located-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1267231138-27856-1-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a47cd880
    • Steven Rostedt's avatar
      ftrace: Add function names to dangling } in function graph tracer · f1c7f517
      Steven Rostedt authored
      The function graph tracer is currently the most invasive tracer
      in the ftrace family. It can easily overflow the buffer even with
      10megs per CPU. This means that events can often be lost.
      
      On start up, or after events are lost, if the function return is
      recorded but the function enter was lost, all we get to see is the
      exiting '}'.
      
      Here is how a typical trace output starts:
      
       [tracing] cat trace
       # tracer: function_graph
       #
       # CPU  DURATION                  FUNCTION CALLS
       # |     |   |                     |   |   |   |
        0) + 91.897 us   |                  }
        0) ! 567.961 us  |                }
        0)   <========== |
        0) ! 579.083 us  |                _raw_spin_lock_irqsave();
        0)   4.694 us    |                _raw_spin_unlock_irqrestore();
        0) ! 594.862 us  |              }
        0) ! 603.361 us  |            }
        0) ! 613.574 us  |          }
        0) ! 623.554 us  |        }
        0)   3.653 us    |        fget_light();
        0)               |        sock_poll() {
      
      There are a series of '}' with no matching "func() {". There's no information
      to what functions these ending brackets belong to.
      
      This patch adds a stack on the per cpu structure used in outputting
      the function graph tracer to keep track of what function was outputted.
      Then on a function exit event, it checks the depth to see if the
      function exit has a matching entry event. If it does, then it only
      prints the '}', otherwise it adds the function name after the '}'.
      
      This allows function exit events to show what function they belong to
      at trace output startup, when the entry was lost due to ring buffer
      overflow, or even after a new task is scheduled in.
      
      Here is what the above trace will look like after this patch:
      
       [tracing] cat trace
       # tracer: function_graph
       #
       # CPU  DURATION                  FUNCTION CALLS
       # |     |   |                     |   |   |   |
        0) + 91.897 us   |                  } (irq_exit)
        0) ! 567.961 us  |                } (smp_apic_timer_interrupt)
        0)   <========== |
        0) ! 579.083 us  |                _raw_spin_lock_irqsave();
        0)   4.694 us    |                _raw_spin_unlock_irqrestore();
        0) ! 594.862 us  |              } (add_wait_queue)
        0) ! 603.361 us  |            } (__pollwait)
        0) ! 613.574 us  |          } (tcp_poll)
        0) ! 623.554 us  |        } (sock_poll)
        0)   3.653 us    |        fget_light();
        0)               |        sock_poll() {
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f1c7f517
  7. 26 Feb, 2010 17 commits
  8. 25 Feb, 2010 11 commits