From: Yury Norov <yury.norov@gmail.com>
To: Kees Cook <kees@kernel.org>
Cc: Brian Norris <briannorris@chromium.org>,
Nathan Chancellor <nathan@kernel.org>,
llvm@lists.linux.dev, linux-kernel@vger.kernel.org,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH v2] bitmap: Switch from inline to __always_inline
Date: Fri, 12 Jul 2024 16:54:48 -0700 [thread overview]
Message-ID: <ZpHCSKuKDjzuSmXx@yury-ThinkPad> (raw)
In-Reply-To: <202407121059.9FC2D0DF@keescook>
On Fri, Jul 12, 2024 at 11:01:13AM -0700, Kees Cook wrote:
> On Fri, Jul 12, 2024 at 10:02:55AM -0700, Yury Norov wrote:
> > Hi Brian,
> >
> > Thanks for taking over this!
> >
> > + Kees Cook for GCC
> > [...]
> > But I'm not sure about that and don't know how to check what happens
> > under the compilers' hood. Can compiler gurus please clarify?
>
> I don't know much about GCC internals. I just ask GCC devs nicely to
> help us where they can. :)
My concern here is that this __always_inline may hide a compiler's
inability to inline things like that properly. In that case, we
shouldn't convert bitmaps, and should file a bug to compilers.
From your and LLVM people comments, it seems it's OK to convert
kernel code. I just want to make it explicit before moving forward.
> > > Subject: [PATCH 1/3] bitmap: switch from inline to __always_inline
>
> We always expected them to be inline, and if we need to hit the
> compilers harder with __always_inline, that seems sensible to me.
>
> Reviewed-by: Kees Cook <kees@kernel.org>
Is that for bitmaps only, or for all files in the patch?
next prev parent reply other threads:[~2024-07-12 23:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 16:37 [PATCH v2] bitmap: Switch from inline to __always_inline Brian Norris
2024-07-12 17:02 ` Yury Norov
2024-07-12 18:01 ` Kees Cook
2024-07-12 23:54 ` Yury Norov [this message]
2024-07-12 20:42 ` Brian Norris
2024-07-13 0:19 ` Yury Norov
2024-07-13 23:27 ` Nathan Chancellor
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=ZpHCSKuKDjzuSmXx@yury-ThinkPad \
--to=yury.norov@gmail.com \
--cc=briannorris@chromium.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@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.