[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170615045221.GA26687@kroah.com>
Date: Thu, 15 Jun 2017 06:52:21 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
kasan-dev@...glegroups.com, Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Arend van Spriel <arend.vanspriel@...adcom.com>,
Jiri Slaby <jslaby@...e.com>,
Samuel Thibault <samuel.thibault@...-lyon.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN
On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
>
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>
> Annotating those functions as noinline_if_stackbloat prevents the inlining
> and reduces the overall stack usage in this driver.
>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> drivers/tty/vt/keyboard.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f4166263bb3a..c0d111444a0e 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
> /*
> * Helper Functions.
> */
> -static void put_queue(struct vc_data *vc, int ch)
> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
> {
> tty_insert_flip_char(&vc->port, ch, 0);
> tty_schedule_flip(&vc->port);
> }
Ugh, really? We have to start telling gcc not to be stupid here?
That's not going to be easy, and will just entail us doing this all over
the place, right?
The code isn't asking to be inlined, so why is gcc allowing it to be
done that way? Doesn't that imply gcc is the problem here?
thanks,
greg k-h
Powered by blists - more mailing lists