From: Nathan Chancellor <natechancellor@gmail.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andy Lutomirski <luto@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Alexander Potapenko <glider@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN
Date: Fri, 21 Sep 2018 02:55:16 -0700 [thread overview]
Message-ID: <20180921095516.GA17326@flashbox> (raw)
In-Reply-To: <CACT4Y+bEf3GQ7zyfFd_PDOW3Cgh0Ot+KbUo4rHij5oSPYPJUNQ@mail.gmail.com>
On Fri, Sep 21, 2018 at 11:45:07AM +0200, Dmitry Vyukov wrote:
> On Fri, Sep 21, 2018 at 11:25 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
> > On 09/21/2018 04:50 AM, Andy Lutomirski wrote:
> >> This patch seems reasonable, but you emailed the wrong people :)
> >>
> >> On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >>>
> >>> It turns out that KASAN in general will bloat stack frames in unexpected
> >>> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> >>> default to be associated with KASAN instead of KASAN_EXTRA.
> >>>
> >
> > KASAN_EXTRA bloats stack more than just KASAN, that's why the limit is higher than just for KASAN.
> > If want more details, tead the changelog from commit e7c52b84fb18f08ce49b6067ae6285aca79084a8
> >
> > If anything causes "stack frame > 2048" warning for KASAN we should at least try to fix it,
> > I mean reduce stack usage.
>
>
> +Nick who is also hitting these warnings on clang/arm64 build. As far
> as I understand the situation there is much worse.
>
> I would be good to understand/fix the worst offenders. But the stack
> size increase with KASAN is a real, inherent thing. So if we live very
> close the edge, we can get people using different compilers and/or
> versions of compilers constantly breaking each other. And clang hits
> this warnings in lots of places today just because the current code
> was tailored to gcc over long period, i.e. allowing more locals where
> gcc happened to handle that better and having fewer locals where gcc
> happened to handle it worse. But for another compiler all these
> assumptions are significantly perturbed.
>
> Nick, do you know what frame size limit eliminates the bulk of
> warnings on clang? Is 3072 a reasonable limit allowing to fix the
> remaining outliners?
>
Hi Dmitry,
I know I'm not Nick and I hope I am not butting in but I've been
following this thread due to these warnings cropping up in Clang.
We've been tracking them on GitHub and judging from the values
there, I would argue that 3072 is a good starting value.
Link: https://github.com/ClangBuiltLinux/linux/issues/39
Cheers,
Nathan
>
> >>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >>> ---
> >>> lib/Kconfig.debug | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> >>> index 4966c4fbe7f7..39078a080e29 100644
> >>> --- a/lib/Kconfig.debug
> >>> +++ b/lib/Kconfig.debug
> >>> @@ -222,7 +222,7 @@ config ENABLE_MUST_CHECK
> >>> config FRAME_WARN
> >>> int "Warn for stack frames larger than (needs gcc 4.4)"
> >>> range 0 8192
> >>> - default 3072 if KASAN_EXTRA
> >>> + default 3072 if KASAN
> >>> default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> >>> default 1280 if (!64BIT && PARISC)
> >>> default 1024 if (!64BIT && !PARISC)
> >>> --
> >>> 2.19.0
next prev parent reply other threads:[~2018-09-21 9:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 0:15 [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN Jason A. Donenfeld
2018-09-21 1:50 ` Andy Lutomirski
2018-09-21 8:42 ` Dmitry Vyukov
2018-09-21 12:11 ` Andrey Konovalov
2018-09-21 9:25 ` Andrey Ryabinin
2018-09-21 9:45 ` Dmitry Vyukov
2018-09-21 9:55 ` Nathan Chancellor [this message]
2018-09-21 17:59 ` Nick Desaulniers
2018-09-21 18:17 ` Nick Desaulniers
2018-09-22 14:56 ` Arnd Bergmann
2018-09-24 8:04 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180921095516.GA17326@flashbox \
--to=natechancellor@gmail.com \
--cc=Jason@zx2c4.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=ndesaulniers@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.