1. 25 Dec, 2008 6 commits
  2. 13 Dec, 2008 1 commit
    • Rusty Russell's avatar
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell authored
      
      
      Impact: cleanup
      
      Each SMP arch defines these themselves.  Move them to a central
      location.
      
      Twists:
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
         declarations.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
      98a79d6a
  3. 28 Oct, 2008 2 commits
    • Heiko Carstens's avatar
      [S390] No more 4kb stacks. · 7f5a8ba6
      Heiko Carstens authored
      
      
      We got a stack overflow with a small stack configuration on a 32 bit
      system. It just looks like as 4kb isn't enough and too dangerous.
      So lets get rid of 4kb stacks on 32 bit.
      
      But one thing I completely dislike about the call trace below is that
      just for debugging or tracing purposes sprintf gets called (cio_start_key):
      
      	/* process condition code */
      	sprintf(dbf_txt, "ccode:%d", ccode);
      	CIO_TRACE_EVENT(4, dbf_txt);
      
      But maybe its just me who thinks that this could be done better.
      
          <4>Kernel stack overflow.
          <4>Modules linked in: dm_multipath sunrpc bonding qeth_l2 dm_mod qeth ccwgroup vmur
          <4>CPU: 1 Not tainted 2.6.27-30.x.20081015-s390default #1
          <4>Process httpd (pid: 3807, task: 20ae2df8, ksp: 1666fb78)
          <4>Krnl PSW : 040c0000 8027098a (number+0xe/0x348)
          <4>           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0
          <4>Krnl GPRS: 00d43318 0027097c 1666f277 9666f270
          <4>           00000000 00000000 0000000a ffffffff
          <4>           9666f270 1666f228 1666f277 1666f098
          <4>           00000002 80270982 80271016 1666f098
          <4>Krnl Code: 8027097e: f0340dd0a7f1	srp	3536(4,%r0),2033(%r10),4
          <4>           80270984: 0f00		clcl	%r0,%r0
          <4>           80270986: a7840001		brc	8,80270988
          <4>          >8027098a: 18ef		lr	%r14,%r15
          <4>           8027098c: a7faff68		ahi	%r15,-152
          <4>           80270990: 18bf		lr	%r11,%r15
          <4>           80270992: 18a2		lr	%r10,%r2
          <4>           80270994: 1893		lr	%r9,%r3
      
      Modified calltrace with annotated stackframe size of each function:
      
      stackframe size
          |
       0 304 vsnprintf+850 [0x271016]
       1  72 sprintf+74 [0x271522]
       2  56 cio_start_key+262 [0x2d4c16]
       3  56 ccw_device_start_key+222 [0x2dfe92]
       4  56 ccw_device_start+40 [0x2dff28]
       5  48 raw3215_start_io+104 [0x30b0f8]
       6  56 raw3215_write+494 [0x30ba0a]
       7  40 con3215_write+68 [0x30bafc]
       8  40 __call_console_drivers+146 [0x12b0fa]
       9  32 _call_console_drivers+102 [0x12b192]
      10  64 release_console_sem+268 [0x12b614]
      11 168 vprintk+462 [0x12bca6]
      12  72 printk+68 [0x12bfd0]
      13 256 __print_symbol+50 [0x15a882]
      14  56 __show_trace+162 [0x103d06]
      15  32 show_trace+224 [0x103e70]
      16  48 show_stack+152 [0x103f20]
      17  56 dump_stack+126 [0x104612]
      18  96 __alloc_pages_internal+592 [0x175004]
      19  80 cache_alloc_refill+776 [0x196f3c]
      20  40 __kmalloc+258 [0x1972ae]
      21  40 __alloc_skb+94 [0x328086]
      22  32 pskb_copy+50 [0x328252]
      23  32 skb_realloc_headroom+110 [0x328a72]
      24 104 qeth_l2_hard_start_xmit+378 [0x7803bfde]
      25  56 dev_hard_start_xmit+450 [0x32ef6e]
      26  56 __qdisc_run+390 [0x3425d6]
      27  48 dev_queue_xmit+410 [0x331e06]
      28  40 ip_finish_output+308 [0x354ac8]
      29  56 ip_output+218 [0x355b6e]
      30  24 ip_local_out+56 [0x354584]
      31 120 ip_queue_xmit+300 [0x355cec]
      32  96 tcp_transmit_skb+812 [0x367da8]
      33  40 tcp_push_one+158 [0x369fda]
      34 112 tcp_sendmsg+852 [0x35d5a0]
      35 240 sock_sendmsg+164 [0x32035c]
      36  56 kernel_sendmsg+86 [0x32064a]
      37  88 sock_no_sendpage+98 [0x322b22]
      38 104 tcp_sendpage+70 [0x35cc1e]
      39  48 sock_sendpage+74 [0x31eb66]
      40  64 pipe_to_sendpage+102 [0x1c4b2e]
      41  64 __splice_from_pipe+120 [0x1c5340]
      42  72 splice_from_pipe+90 [0x1c57e6]
      43  56 generic_splice_sendpage+38 [0x1c5832]
      44  48 do_splice_from+104 [0x1c4c38]
      45  48 direct_splice_actor+52 [0x1c4c88]
      46  80 splice_direct_to_actor+180 [0x1c4f80]
      47  72 do_splice_direct+70 [0x1c5112]
      48  64 do_sendfile+360 [0x19de18]
      49  72 sys_sendfile64+126 [0x19df32]
      50 336 sysc_do_restart+18 [0x111a1a]
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      7f5a8ba6
    • Heiko Carstens's avatar
      [S390] Change default IPL method to IPL_VM. · 46e7951f
      Heiko Carstens authored
      
      
      allyesconfig and allmodconfig built kernels have a tape IPL record.
      A the vmreader record makes much more sense, since hardly anybody will
      ever IPL a kernel from tape. So change the default.
      As I side effect I can test these kernels without fiddling around with
      the kernel config ;)
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      46e7951f
  4. 20 Oct, 2008 1 commit
    • Matt Helsley's avatar
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley authored
      
      
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  5. 15 Oct, 2008 1 commit
  6. 10 Oct, 2008 1 commit
  7. 01 Aug, 2008 1 commit
  8. 24 Jul, 2008 1 commit
  9. 17 Jul, 2008 1 commit
    • Heiko Carstens's avatar
      [S390] Increase default warning stacksize. · c5a37255
      Heiko Carstens authored
      
      
      Compiling a kernel with allmodconfig or allyesconfig results in tons
      of gcc warnings, because the default maximum stacksize from which on
      gcc will emit a warning is just 256 bytes.
      Increase this to 2048, so these warnings don't distract from the real
      warnings that we need to watch at.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      c5a37255
  10. 14 Jul, 2008 3 commits
  11. 10 Jun, 2008 1 commit
  12. 30 May, 2008 1 commit
  13. 07 May, 2008 1 commit
  14. 30 Apr, 2008 1 commit
  15. 27 Apr, 2008 3 commits
  16. 16 Apr, 2008 3 commits
  17. 05 Mar, 2008 1 commit
    • Heiko Carstens's avatar
      [S390] Fix IPL from NSS. · 684de39b
      Heiko Carstens authored
      
      
      IPL from NSS didn't work because the memory detection routine omits any
      memory sections with a size lower than what MAX_ORDER defines.
      This causes the detection routine to skip the first memory segment which
      has a size of 1MB. Which later on will let the kernel think that there
      is no memory available at all.
      Since in addition the z/VM memory increment size is 1MB force MAX_ORDER
      to be 9, so we can support 1MB segments.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      684de39b
  18. 04 Mar, 2008 1 commit
  19. 19 Feb, 2008 1 commit
  20. 05 Feb, 2008 2 commits
  21. 03 Feb, 2008 4 commits
    • Adrian Bunk's avatar
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk authored
      
      
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      place.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      03502faa
    • Mathieu Desnoyers's avatar
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers authored
      
      
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      125e5645
    • Mathieu Desnoyers's avatar
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers authored
      
      
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      3f550096
    • Mathieu Desnoyers's avatar
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers authored
      
      
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      42d4b839
  22. 26 Jan, 2008 1 commit
  23. 30 Oct, 2007 1 commit
  24. 19 Oct, 2007 1 commit