From: Daniel Micay <danielmicay@gmail.com>
To: kbuild test robot <lkp@intel.com>, Kees Cook <keescook@chromium.org>
Cc: kbuild-all@01.org, Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
David Howells <dhowells@redhat.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fortify: Use WARN instead of BUG for now
Date: Thu, 27 Jul 2017 12:48:47 -0400 [thread overview]
Message-ID: <1501174127.26391.1.camel@gmail.com> (raw)
In-Reply-To: <201707271305.eiZ8s96C%fengguang.wu@intel.com>
I think the 'else' added in the proposed patch makes it too complicated
for GCC to optimize out the __attribute__((error)) checks before they're
considered to be errors. It's not needed so it's probably best to just
avoid doing something like that. The runtime checks can't get false
positives from overly complex code but the compile-time ones depend on
GCC being able to reliably optimize them out.
This might be easier for GCC:
if (__builtin_constant_p(size) && condition_a) {
compiletimeerror();
}
if (__builtin_constant_p(size) && condition_b) {
compiletimeerror();
}
than the current:
if (__builtin_constant_p(size)) {
if (condition_a) {
compiletimeerror();
}
if (condition_b) {
compiletimeerror();
}
}
but it hasn't had a false positive like that with the current code.
Removing __noreturn is making the inline code more complex from GCC's
perspective too, but hopefully it's neither reducing coverage (i.e. not
making it less able to resolve __builtin_object_size - intuitively it
shouldn't impact it much but you never know) or making GCC unable to
deal with the compile-time checks.
prev parent reply other threads:[~2017-07-27 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 3:50 [PATCH] fortify: Use WARN instead of BUG for now Kees Cook
2017-07-26 12:52 ` Daniel Micay
2017-07-26 17:21 ` Kees Cook
2017-07-26 17:57 ` Daniel Micay
2017-07-26 17:10 ` Linus Torvalds
2017-07-26 17:17 ` Kees Cook
2017-07-27 6:01 ` kbuild test robot
2017-07-27 16:48 ` Daniel Micay [this message]
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=1501174127.26391.1.camel@gmail.com \
--to=danielmicay@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=kbuild-all@01.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mchehab@kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox