Commit Graph

4 Commits

Author SHA1 Message Date
Heiko Carstens 7f5a8ba6b0 [S390] No more 4kb stacks.
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: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-28 11:12:06 +01:00
Matt Helsley 83224b0837 container freezer: add TIF_FREEZE flag to all architectures
This patch series introduces a cgroup subsystem that utilizes the swsusp
freezer to freeze a group of tasks.  It's immediately useful for batch job
management scripts.  It should also be useful in the future for
implementing container checkpoint/restart.

The freezer subsystem in the container filesystem defines a cgroup file
named freezer.state.  Reading freezer.state will return the current state
of the cgroup.  Writing "FROZEN" to the state file will freeze all tasks
in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
the cgroup.

* 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 patch:

The first step in making the refrigerator() available to all
architectures, even for those without power management.

The purpose of such a change is to be able to use the refrigerator() in a
new control group subsystem which will implement a control group freezer.

[akpm@linux-foundation.org: fix sparc]
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Serge E. Hallyn <serue@us.ibm.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@tuxonice.net>
Tested-by: Matt Helsley <matthltc@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-20 08:52:33 -07:00
Martin Schwidefsky 753c4dd6a2 [S390] ptrace changes
* System call parameter and result access functions
* Add tracehook calls
* Split syscall_trace into two functions do_syscall_trace_enter and
  do_syscall_trace_exit

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-10 21:33:57 +02:00
Martin Schwidefsky c6557e7f2b [S390] move include/asm-s390 to arch/s390/include/asm
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-08-01 20:42:05 +02:00