1. 28 Jul, 2010 1 commit
  2. 03 Jun, 2010 1 commit
  3. 25 May, 2010 3 commits
  4. 21 May, 2010 2 commits
  5. 17 May, 2010 1 commit
    • Heiko Carstens's avatar
      [S390] debug: enable exception-trace debug facility · ab3c68ee
      Heiko Carstens authored
      
      
      The exception-trace facility on x86 and other architectures prints
      traces to dmesg whenever a user space application crashes.
      s390 has such a feature since ages however it is called
      userprocess_debug and is enabled differently.
      This patch makes sure that whenever one of the two procfs files
      
      /proc/sys/kernel/userprocess_debug
      /proc/sys/debug/exception-trace
      
      is modified the contents of the second one changes as well.
      That way we keep backwards compatibilty but also support the same
      interface like other architectures do.
      Besides that the output of the traces is improved since it will now
      also contain the corresponding filename of the vma (when available)
      where the process caused a fault or trap.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      ab3c68ee
  6. 16 May, 2010 2 commits
    • Octavian Purdila's avatar
      sysctl: add proc_do_large_bitmap · 9f977fb7
      Octavian Purdila authored
      
      
      The new function can be used to read/write large bitmaps via /proc. A
      comma separated range format is used for compact output and input
      (e.g. 1,3-4,10-10).
      
      Writing into the file will first reset the bitmap then update it
      based on the given input.
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f977fb7
    • Amerigo Wang's avatar
      sysctl: refactor integer handling proc code · 00b7c339
      Amerigo Wang authored
      
      
      (Based on Octavian's work, and I modified a lot.)
      
      As we are about to add another integer handling proc function a little
      bit of cleanup is in order: add a few helper functions to improve code
      readability and decrease code duplication.
      
      In the process a bug is also fixed: if the user specifies a number
      with more then 20 digits it will be interpreted as two integers
      (e.g. 10000...13 will be interpreted as 100.... and 13).
      
      Behavior for EFAULT handling was changed as well. Previous to this
      patch, when an EFAULT error occurred in the middle of a write
      operation, although some of the elements were set, that was not
      acknowledged to the user (by shorting the write and returning the
      number of bytes accepted). EFAULT is now treated just like any other
      errors by acknowledging the amount of bytes accepted.
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00b7c339
  7. 14 Apr, 2010 1 commit
    • Dmitry Torokhov's avatar
      Input: implement SysRq as a separate input handler · 97f5f0cd
      Dmitry Torokhov authored
      
      
      Instead of keeping SysRq support inside of legacy keyboard driver split
      it out into a separate input handler (filter). This stops most SysRq input
      events from leaking into evdev clients (some events, such as first SysRq
      scancode - not keycode - event, are still leaked into both legacy keyboard
      and evdev).
      
      [martinez.javier@gmail.com: fix compile error when CONFIG_MAGIC_SYSRQ is
       not defined]
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      97f5f0cd
  8. 12 Mar, 2010 8 commits
  9. 01 Mar, 2010 1 commit
  10. 25 Feb, 2010 1 commit
    • Masami Hiramatsu's avatar
      kprobes: Jump optimization sysctl interface · b2be84df
      Masami Hiramatsu authored
      
      
      Add /proc/sys/debug/kprobes-optimization sysctl which enables
      and disables kprobes jump optimization on the fly for debugging.
      
      Changes in v7:
       - Remove ctl_name = CTL_UNNUMBERED for upstream compatibility.
      
      Changes in v6:
      - Update comments and coding style.
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Cc: systemtap <systemtap@sources.redhat.com>
      Cc: DLE <dle-develop@lists.sourceforge.net>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Anders Kaseorg <andersk@ksplice.com>
      Cc: Tim Abbott <tabbott@ksplice.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      LKML-Reference: <20100225133415.6725.8274.stgit@localhost6.localdomain6>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b2be84df
  11. 17 Dec, 2009 1 commit
  12. 16 Dec, 2009 1 commit
  13. 15 Dec, 2009 2 commits
    • Amerigo Wang's avatar
      'sysctl_max_map_count' should be non-negative · 70da2340
      Amerigo Wang authored
      
      
      Jan Engelhardt reported we have this problem:
      
      setting max_map_count to a value large enough results in programs dying at
      first try.  This is on 2.6.31.6:
      
      15:59 borg:/proc/sys/vm # echo $[1<<31-1] >max_map_count
      15:59 borg:/proc/sys/vm # cat max_map_count
      1073741824
      15:59 borg:/proc/sys/vm # echo $[1<<31] >max_map_count
      15:59 borg:/proc/sys/vm # cat max_map_count
      Killed
      
      This is because we have a chance to make 'max_map_count' negative.  but
      it's meaningless.  Make it only accept non-negative values.
      Reported-by: default avatarJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: James Morris <jmorris@namei.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70da2340
    • Lee Schermerhorn's avatar
      hugetlb: derive huge pages nodes allowed from task mempolicy · 06808b08
      Lee Schermerhorn authored
      
      
      This patch derives a "nodes_allowed" node mask from the numa mempolicy of
      the task modifying the number of persistent huge pages to control the
      allocation, freeing and adjusting of surplus huge pages when the pool page
      count is modified via the new sysctl or sysfs attribute
      "nr_hugepages_mempolicy".  The nodes_allowed mask is derived as follows:
      
      * For "default" [NULL] task mempolicy, a NULL nodemask_t pointer
        is produced.  This will cause the hugetlb subsystem to use
        node_online_map as the "nodes_allowed".  This preserves the
        behavior before this patch.
      * For "preferred" mempolicy, including explicit local allocation,
        a nodemask with the single preferred node will be produced.
        "local" policy will NOT track any internode migrations of the
        task adjusting nr_hugepages.
      * For "bind" and "interleave" policy, the mempolicy's nodemask
        will be used.
      * Other than to inform the construction of the nodes_allowed node
        mask, the actual mempolicy mode is ignored.  That is, all modes
        behave like interleave over the resulting nodes_allowed mask
        with no "fallback".
      
      See the updated documentation [next patch] for more information
      about the implications of this patch.
      
      Examples:
      
      Starting with:
      
      	Node 0 HugePages_Total:     0
      	Node 1 HugePages_Total:     0
      	Node 2 HugePages_Total:     0
      	Node 3 HugePages_Total:     0
      
      Default behavior [with or without this patch] balances persistent
      hugepage allocation across nodes [with sufficient contiguous memory]:
      
      	sysctl vm.nr_hugepages[_mempolicy]=32
      
      yields:
      
      	Node 0 HugePages_Total:     8
      	Node 1 HugePages_Total:     8
      	Node 2 HugePages_Total:     8
      	Node 3 HugePages_Total:     8
      
      Of course, we only have nr_hugepages_mempolicy with the patch,
      but with default mempolicy, nr_hugepages_mempolicy behaves the
      same as nr_hugepages.
      
      Applying mempolicy--e.g., with numactl [using '-m' a.k.a.
      '--membind' because it allows multiple nodes to be specified
      and it's easy to type]--we can allocate huge pages on
      individual nodes or sets of nodes.  So, starting from the
      condition above, with 8 huge pages per node, add 8 more to
      node 2 using:
      
      	numactl -m 2 sysctl vm.nr_hugepages_mempolicy=40
      
      This yields:
      
      	Node 0 HugePages_Total:     8
      	Node 1 HugePages_Total:     8
      	Node 2 HugePages_Total:    16
      	Node 3 HugePages_Total:     8
      
      The incremental 8 huge pages were restricted to node 2 by the
      specified mempolicy.
      
      Similarly, we can use mempolicy to free persistent huge pages
      from specified nodes:
      
      	numactl -m 0,1 sysctl vm.nr_hugepages_mempolicy=32
      
      yields:
      
      	Node 0 HugePages_Total:     4
      	Node 1 HugePages_Total:     4
      	Node 2 HugePages_Total:    16
      	Node 3 HugePages_Total:     8
      
      The 8 huge pages freed were balanced over nodes 0 and 1.
      
      [rientjes@google.com: accomodate reworked NODEMASK_ALLOC]
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarLee Schermerhorn <lee.schermerhorn@hp.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Reviewed-by: default avatarAndi Kleen <andi@firstfloor.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Nishanth Aravamudan <nacc@us.ibm.com>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Eric Whitney <eric.whitney@hp.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      06808b08
  14. 09 Dec, 2009 3 commits
  15. 18 Nov, 2009 1 commit
  16. 12 Nov, 2009 1 commit
  17. 11 Nov, 2009 3 commits
  18. 06 Nov, 2009 1 commit
  19. 24 Sep, 2009 3 commits
  20. 23 Sep, 2009 1 commit
  21. 22 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      printk: Remove ratelimit.h from kernel.h · 3fff4c42
      Ingo Molnar authored
      
      
      Decouple kernel.h from ratelimit.h: the global declaration of
      printk's ratelimit_state is not needed, and it leads to messy
      circular dependencies due to ratelimit.h's (new) adding of a
      spinlock_types.h include.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3fff4c42
  22. 21 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar authored
      Bye-bye Performance Counters, welcome Performance Events!
      
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      
      User-space tooling and ABI compatibility is not af...
      cdd6c482