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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAK8P3a1bZ6DBFRy+HCax-=jj2rTa+hCkK8VOSRvX56CLAz23Ew@mail.gmail.com>
Date:   Fri, 14 May 2021 20:33:58 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "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>,
        Linux Kernel Mailing List <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 4:16 PM 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).

It's not really internal behavior of the compiler that causes the smaller
scope to help here, I'm sure gcc has to do the same thing regarding
the placement of this variable on the stack. Clang does have some related
cases that it doesn't do as well as gcc, but I don't think this is one of them.

The difference between the compilers or configurations is the way that
inlining decisions are made, so if a compiler inlines another function into this
one that also uses a lot of stack space, that will trigger the warning, while
a compiler that does not inline that would not warn but also not use any
less stack space in the code path that uses the nested function.

> > diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> > index c1abd63f1d6c..e3fe84f017a8 100644
> > --- a/kernel/trace/trace_events_hist.c
> > +++ b/kernel/trace/trace_events_hist.c
> > @@ -4597,7 +4597,6 @@ static void hist_trigger_print_key(struct seq_file *m,
> >                                  struct tracing_map_elt *elt)
> >  {
> >       struct hist_field *key_field;
> > -     char str[KSYM_SYMBOL_LEN];
>
> Instead, I think we should just make str static, as this should only be
> called under the event_mutex. To be sure, we can also add:
>
>         /* To protect the static str variable */
>         lockdep_assert_held(&event_mutex);

Ok, I changed my local version to this, will send v2 once it passes
some more randconfig builds.

         Arnd