Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

[Sven Schnelle <svens@linux.ibm.com>]

Hi Kees,

Kees Cook <keescook@chromium.org> writes:

> On Fri, May 26, 2023 at 03:42:56PM +0200, Heiko Carstens wrote:
>> Hi Kees,
>> 
>> > I had this[1] patch pointed out to me, but I couldn't find any discussion
>> > about it on public lists. Can you give me some background on this? There
>> > haven't been any general workloads identified where this has been
>> > a problem, so I'm curious why this was seen as globally an issue on
>> > s390. The expectation was to use __uninitialized on any variables where
>> > this was noticed as a performance issue, and where the memory safety of
>> > the variable could be proven. Turning it off by default seems like
>> > rather too much, but perhaps there is something unique to s390 I don't
>> > know about. :)
>> 
>> This was the result of some micro benchmarks being reported "too slow".
>> Actually our syscall entry/exit path got naturally slower since we switched
>> to generic entry; now we are trying to improve things a bit again.
>> 
>> There is also this RFC from Sven, which tries to inline some of the
>> generic system call functions, in order to avoid function calls:
>> https://lore.kernel.org/lkml/20230516133810.171487-1-svens@linux.ibm.com/
>> 
>> I stumbled upon CONFIG_INIT_STACK_NONE only by accident when wondering why
>> the compiler would generate quite some instructions which aren't necessary,
>> just to zero variables. For the getpid() system call this makes a runtime
>> difference of ~3%, which is quite a bit.
>
> Hm, that does seem high. It implies there are large variable that are
> being passed by reference, perhaps in the syscall path? I had similar
> problems a while back on x86 but due to stack-protector seeing the
> register arrays and thinking they needed protection. I had to explicitly
> turn that off for the entry code, since they're provably safe. :)

From looking at our s390 specific entry code i don't see big arrays on
the stack, but let me do some profiling. Maybe i missed something.

Regards,
Sven