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] [day] [month] [year] [list]

Message-ID: <CAK8P3a1KkFb-pk5XkEa+MnFBPfzMTdUCKMWH+ANQLdfHbp2FWg@mail.gmail.com>
Date:   Fri, 14 May 2021 23:14:20 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        "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 10:19 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@...glegroups.com> wrote:
>
> 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.

Right, I did not manage to find the exact conditions that trigger it.
I did *not* see it with KASAN enabled and I saw it with UBSAN both
on or off.

       Arnd