linux-kernel - Re: [PATCH] tracing: events_hist: avoid using excessive stack space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 May 2021 13:19:24 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Arnd Bergmann <arnd@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Steven Rostedt (VMware)" <rostedt@...mis.org>,
        Tom Zanussi <zanussi@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Qiujun Huang <hqjagain@...il.com>, Tom Rix <trix@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] tracing: events_hist: avoid using excessive stack space

On Fri, May 14, 2021 at 7:16 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Fri, 14 May 2021 16:04:25 +0200
> Arnd Bergmann <arnd@...nel.org> wrote:
>
> > From: Arnd Bergmann <arnd@...db.de>
> >
> > In some configurations, clang produces a warning about an overly large
> > amount of stack space used in hist_trigger_print_key():
> >
> > kernel/trace/trace_events_hist.c:4594:13: error: stack frame size of 1248 bytes in function 'hist_trigger_print_key' [-Werror,-Wframe-larger-than=]
> > static void hist_trigger_print_key(struct seq_file *m,
> >
> > Moving the 'str' variable into a more local scope in the two places
> > where it gets used actually reduces the the used stack space here
> > and gets it below the warning limit, because the compiler can now
> > assume that it is safe to use the same stack slot that it has for
> > the stack of any inline function.
>
> Thanks Arnd for the nice explanation of the rationale for this change.
>
> But I still find it too subtle to my liking that we need to move the
> declaration like this (and duplicate it twice) for internal behavior of the
> compiler (where it can't figure out itself by the use cases if it can
> optimize the stack).

Under which configurations this warning was observed wasn't specified,
but I'd bet it's one of the sanitizers splitting this in two in order
to tell which branch may have overflowed the buffer.

-- 
Thanks,
~Nick Desaulniers