All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>,
	linux-fsdevel@vger.kernel.org,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Andi Kleen <ak@linux.intel.com>, Christoph Hellwig <hch@lst.de>,
	Eric Dumazet <edumazet@google.com>,
	 "Darrick J. Wong" <darrick.wong@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	 Paul Kirth <paulkirth@google.com>
Subject: Re: [PATCH] fs/select: avoid clang stack usage warning
Date: Mon, 10 Oct 2022 11:40:28 -0700	[thread overview]
Message-ID: <CAKwvOdmWvDBw9MnO==dZ8i=gqbVPSUuiuRtwKmWuV8uXzJYNww@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdmNiSok3sAMJs2PQLs0yVzOfMTaQTWjyW8q2oc3VF60sw@mail.gmail.com>

On Fri, Oct 7, 2022 at 3:54 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> This seems to be affected by -fno-conserve-stack, a currently gcc-only
> command line flag. If I remove that, then i386 defconfig will inline
> do_select but x86_64 defconfig will not.
>
> I have a sneaking suspicion that -fno-conserve-stack and
> -Wframe-larger-than conspire in GCC to avoid inlining when doing so
> would trip `-Wframe-larger-than` warnings, but it's just a conspiracy
> theory; I haven't read the source.  Probably should implement exactly
> that behavior in LLVM.

Sorry, that should have read `-fconserve-stack` (not `-fno-conserve-stack`).

Playing with:
https://godbolt.org/z/hE67j1Y9G
experimentally, it looks like irrespective of -Wframe-larger-than,
-fconserve-stack will try to avoid inlining callees if their frame
size is 512B or greater for x86-64 targets, and 410B or greater for
32b targets. aarch64 is 410B though, perhaps that's leftover from the
32b ARM port.  There's probably more to the story there though.

> I'll triple check 32b+64b arm configs next week to verify.  But if GCC
> is not inlining do_select into core_sys_select then I think my patch
> https://lore.kernel.org/llvm/20221007201140.1744961-1-ndesaulniers@google.com/
> is on the right track; probably could drop the 32b-only condition and
> make a note of GCC in the commit message.

arm64 does not inline do_select into core_sys_select with
aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110
for defconfig.

$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make -j128 defconfig fs/select.o
$ llvm-objdump -Dr --disassemble-symbols=core_sys_select fs/select.o |
grep do_select
    1a48: 2e fb ff 97  bl 0x700 <do_select>

Same for 32b ARM.
arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110

$ CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make -j128 defconfig fs/select.o
$ llvm-objdump -Dr --disassemble-symbols=core_sys_select fs/select.o |
grep do_select
    1620: 07 fc ff eb  bl #-4068 <do_select>

Is there a set of configs or different compiler version for which
that's not the case? Perhaps. But it doesn't look like marking
do_select noinline_for_stack changes the default behavior for GCC
builds, which is good.

So it looks like it's just clang being aggressive with inlining since
it doesn't have -fconserve-stack.  I think
https://lore.kernel.org/lkml/20221007201140.1744961-1-ndesaulniers@google.com/
is still on the right track, though I'd remove the 32b only guard for
v2.

Christophe mentioned something about KASAN and GCC. I failed to
reproduce, and didn't see any reports on lore that seemed relevant.
https://lore.kernel.org/lkml/20221010074409.GA20998@lst.de/
I'll wait a day to see if there's more info (a config that reproduces)
before sending a v2 though.

> Also, my colleague Paul just whipped up a neat tool to help debug
> -Wframe-larger-than.
> https://reviews.llvm.org/D135488
> See the output from my run here:
> https://paste.debian.net/1256338/
> It's a very early WIP, but I think it would be incredibly helpful to
> have this, and will probably help us improve Clang's stack usage.

Paul also mentioned that -finline-max-stacksize is a thing, at least for clang.
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-finline-max-stacksize
Though this only landed recently
https://reviews.llvm.org/rG8564e2fea559 and wont ship until clang-16.
That feels like a large hammer for core_sys_select/do_select; I think
we can use a fine scalpel.  But it might be interesting to use that
with KASAN.
-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2022-10-10 18:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07  9:01 [PATCH] fs/select: avoid clang stack usage warning Arnd Bergmann
2019-03-07 16:19 ` Andi Kleen
2022-10-06 22:21 ` Nick Desaulniers
2022-10-07  8:28   ` Arnd Bergmann
2022-10-07 19:04     ` Nick Desaulniers
2022-10-07 20:11       ` [PATCH] fs/select: mark do_select noinline_for_stack for 32b Nick Desaulniers
2022-10-10  7:44         ` Christoph Hellwig
2022-10-10 16:42           ` Nick Desaulniers
2022-10-10 19:55         ` Arnd Bergmann
2022-10-13 18:52         ` kernel test robot
2022-10-07 21:42       ` [PATCH] fs/select: avoid clang stack usage warning Arnd Bergmann
2022-10-07 22:54         ` Nick Desaulniers
2022-10-10 18:40           ` Nick Desaulniers [this message]
2022-10-11 12:46             ` Arnd Bergmann
2022-10-11 20:55               ` [PATCH v2] fs/select: mark do_select noinline_for_stack Nick Desaulniers
2022-10-14 22:39                 ` Nathan Chancellor
2022-10-07 23:17         ` [PATCH] fs/select: avoid clang stack usage warning Kees Cook
2022-10-09 10:49       ` David Laight
2022-10-08  1:46   ` Andi Kleen
2022-10-11 20:50     ` Nick Desaulniers
2022-10-13 20:52       ` Andi Kleen

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='CAKwvOdmWvDBw9MnO==dZ8i=gqbVPSUuiuRtwKmWuV8uXzJYNww@mail.gmail.com' \
    --to=ndesaulniers@google.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=darrick.wong@oracle.com \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=paulkirth@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.