Bug 111902 - reduce stack usage
reduce stack usage
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
s390 Linux
high Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
: 164435 (view as bug list)
Depends On:
Blocks: 113479
  Show dependency treegraph
Reported: 2003-12-11 09:48 EST by Ingolf Salm
Modified: 2007-11-30 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 15:54:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch for bugzilla 111902 (11.55 KB, patch)
2004-01-23 09:30 EST, Ingolf Salm
no flags Details | Diff
Dr. Weigand re. small frame gcc support (5.26 KB, text/plain)
2004-02-19 15:21 EST, Pete Zaitcev
no flags Details
Applies to 2.4.21-20.EL, also flood-limited (13.06 KB, patch)
2004-08-31 19:46 EDT, Pete Zaitcev
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:550 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 4 2004-12-20 00:00:00 EST

  None (edit)
Description Ingolf Salm 2003-12-11 09:48:59 EST
Description of problem:

symptom: symlink loops on NFS share causes oops
problem: stack overflow
solution: reduce stack usage by inlining some functions and check for 
stack usage
Comment 1 Tim Burke 2003-12-11 10:47:15 EST
Is IBM proactively working this; or just pointing out an issue?  Due
to the absence of much info here, its hard to tell what the intentions
are.  There's not even any description of how to reproduce.
Comment 2 Bob Johnson 2003-12-11 10:51:47 EST
Ingolf, Is this part of the U2 requests or a new bug ?
Either way, as TIm points out, we need more info to go on here, thanks.
Comment 3 Ingolf Salm 2004-01-19 04:22:37 EST
the LTC bugzilla reference is 3344; for patch see developerwork 
Comment 4 Ingolf Salm 2004-01-23 09:30:30 EST
Created attachment 97208 [details]
patch for bugzilla 111902

corresponding diff attached for bugzilla 111902
Comment 7 Pete Zaitcev 2004-02-19 15:20:32 EST
Dr. Ulrich Weigand replied to my queries about an alternative
execution model support in gcc, with smaller frames. He is not
as radical as I would like, he targets only 30% reduction.
See the attachement with e-mail.
Comment 8 Pete Zaitcev 2004-02-19 15:21:35 EST
Created attachment 97840 [details]
Dr. Weigand re. small frame gcc support
Comment 12 Bob Johnson 2004-03-03 11:45:05 EST
Posting the last commentary that I have on this.
IBM thought one of the solutions was in.

From: 	Pete Zaitcev <zaitcev@redhat.com>
To: 	schwidefsky@de.ibm.com
Cc: 	weigand@immd1.informatik.uni-erlangen.de, zaitcev@redhatcom,
laroche@redhat.com, salm@de.ibm.com, bjohnson@redhat.com
Subject: 	Stack frame on s390/64
Date: 	Mon, 16 Feb 2004 14:07:58 -0800	

Hi, Martin:Ingolf filed yet another bug which simply adds insane
inlining in hopes toreduce the stack usage. This time, there's a new
twist: an ethernet driverchecking for impeding stack overflow. I am
sorry, but this is way out ofwhat I would call reasonable. I sense a
sheer desperation if patches likethat start to circulate. Indeed, we
exhausted all standard medicine:we do have interrupt stacks and we run
order 2 process stacks. Looks likeit's time for cure-or-kill
treatment.I propose one of two things.#1. Virtual order 3 (THREE)
stack.#2. New calling convention for C and assembly code in kernel,
which would    only save R12-R15, leaving everything else volatile;
dispose of all    the garbage such as EOS, scratch and alignment
areas.Either of the above has drawbacks, which I am pondering now.
Please letme know if you thought about this and if you have any
additional input.Yours,-- Pete
Comment 14 Pete Zaitcev 2004-03-03 11:55:58 EST
Attachement in the comment #8 was initiated by the message
quoted by Bob in comment #12 and finalized the discussion.
A remapped stack has its drawbacks, such as: excess memory
consumption, especially for Java applications; need to manage
the virtual space into which it's remapped; incompatibility
with DMA. I and IBM rejected it pretty early into discussion.
Comment 16 Pete Zaitcev 2004-03-03 12:39:03 EST
The whole reason I mentioned the vmalloc-ed stack is because
I can work on it without IBM help, but I cannot hack on GCC
without Dr. Weigand's involvement. It is a worse approach.
But since IBM is helpful, we should not aim to inferior solution.
Dr. Weigand is or was an IBM employee and works somewhere near
Ingolf's group in Germany.

[I consulted our Tools group, but they also did not want to be
involved unless Dr. Weigand blessed the changes.]
Comment 17 Ingolf Salm 2004-03-04 03:02:35 EST
Martin's answer: Uli will someday work on the gcc support to reduce 
the stack frame
size but this won't help us in the near future. Certainly not for
RHEL3. But we need a solution for the kernel stack overflow we
experienced with qeth and the current implementation of the tcp/ip
stack. Our solution is to add a few inlines to the qeth driver and
a safe-guard in the tx-function that prevents the kernel stack
overflow if the tcp/ip stack called the driver while already very
deeply nested. This is certainly better than to crash the kernel.
Comment 18 Ingolf Salm 2004-03-04 09:46:35 EST
the patch has no common code dependencies.
Comment 21 Pete Zaitcev 2004-03-10 12:06:44 EST
On a call, Martin Schwindefsky said that he didn't add the asm
kludge to ctc/iucv because they did not use qdio, so they didn't
use quite so much stack. FYI/FOI.

Everyone is disgusted with the approach. One thing I personally
dislike is how inlines hurt debuggability. There's a small question
of bloat as well; layering violation by putting asm into drivers;
also, there's no guarantee that the problem is fixed for good.

One important matter to consider is that a compiler fix blows
ABI promises out from the water. However, its benefits are so
great that I am advocating pushing this direction even in 2.4.

Comment 24 Pete Zaitcev 2004-07-12 17:00:28 EDT
Not the beta, but it's s390 specific, so might as well make U3.
I only had architectural objections above, not practical objections.
I can invoke arch-specific ACK exemption for this if needed.
Comment 31 Pete Zaitcev 2004-08-31 19:46:17 EDT
Created attachment 103321 [details]
Applies to 2.4.21-20.EL, also flood-limited
Comment 32 Ernie Petrides 2004-09-14 20:12:27 EDT
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.6.EL).
Comment 33 John Flanagan 2004-12-20 15:54:49 EST
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

Comment 34 Ernie Petrides 2005-07-27 19:12:45 EDT
*** Bug 164435 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.