[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72a95f0949d149d1b07bd161f3d59cc1@AcuMS.aculab.com>
Date: Mon, 18 Jul 2022 07:51:45 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Michael Ellerman' <mpe@...erman.id.au>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Kees Cook <keescook@...omium.org>
CC: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: RE: mainline build failure of powerpc allmodconfig for
prom_init_check
From: Michael Ellerman
> Sent: 18 July 2022 05:41
...
> So we're memsetting all of args to 254, not zero.
>
> That's happening because allmodconfig with gcc 12 enables
> CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.
I can't help feeling it would be better if that generated
a call to a memset64() function.
Saving loads of tests at the top of the function,
and (most of?) the constant expansion to 64bit.
Although and explicit 'stack clear' function would be better
for the kernel - since it would give the option of patching
it away at startup.
I really can't help feeling that initialising on-stack
arrays will kill performance.
While kernel stack frames have to be relatively small,
in userspace very large on-stack arrays can be allocated
(and correctly bound checked) knowing that the cost is
minimal (maybe a TLB miss).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists