From: Daniel Micay <danielmicay@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: 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>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fortify: Use WARN instead of BUG for now
Date: Wed, 26 Jul 2017 13:57:20 -0400 [thread overview]
Message-ID: <1501091840.1196.12.camel@gmail.com> (raw)
In-Reply-To: <CAGXu5jLrmEGYq7175DAopZNMGP3sP_1a95Fn7jzKcvRQar1S=A@mail.gmail.com>
> Maybe we could do two phases? One to s/BUG/WARN/ and the second to
> improve the message?
s/fortify_panic/fortify_overflow/ + use WARN + remove __noreturn makes
sense as one commit. Still think the *option* of __noreturn + BUG should
be kept there even just for measuring the size overhead. !COMPILE_TIME
&& EXPERT if it needs to be for now. If you're fully removing __noreturn
then the entry in tools/objtool/check.c for __noreturn functions also
won't make sense (either way it needs to use the new name).
I think improving error messages should be done a bit differently though
and it'll be easier to not tie these things together.
next prev parent reply other threads:[~2017-07-26 17:57 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 [this message]
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
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=1501091840.1196.12.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=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.