Bug 111902

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.

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.

the LTC bugzilla reference is 3344; for patch see developerwork 
http://www10.software.ibm.com/developerworks/opensource/linux390/linux
-2.4.21-s390-05-june2003.shtml 

Created attachment 97208 [details]
patch for bugzilla 111902

corresponding diff attached for bugzilla 111902

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.

Created attachment 97840 [details]
Dr. Weigand re. small frame gcc support

Posting the last commentary that I have on this.
IBM thought one of the solutions was in.

From: 	Pete Zaitcev <zaitcev>
To: 	schwidefsky.com
Cc: 	weigand.uni-erlangen.de, zaitcev@redhatcom,
laroche, salm.com, bjohnson
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

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.

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.]

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.

the patch has no common code dependencies.

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.

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.

Created attachment 103321 [details]
Applies to 2.4.21-20.EL, also flood-limited

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).

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.

http://rhn.redhat.com/errata/RHBA-2004-550.html

*** Bug 164435 has been marked as a duplicate of this bug. ***