linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Ian Abbott <abbotti@mev.co.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Alexander Potapenko <glider@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@suse.de>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v5 5/6] bug: split BUILD_BUG stuff out into <linux/build_bug.h>
Date: Thu, 25 May 2017 11:30:01 -0700	[thread overview]
Message-ID: <CAGXu5jKukZxGK_hk77Acq0omtTEnRp-YXF+Y58db5AyZjD5t2Q@mail.gmail.com> (raw)
In-Reply-To: <20170525120316.24473-6-abbotti@mev.co.uk>

On Thu, May 25, 2017 at 5:03 AM, Ian Abbott <abbotti@mev.co.uk> wrote:
> Including <linux/bug.h> pulls in a lot of bloat from <asm/bug.h> and
> <asm-generic/bug.h> that is not needed to call the BUILD_BUG() family of
> macros.  Split them out into their own header, <linux/build_bug.h>.
>
> Also correct some checkpatch.pl errors for the BUILD_BUG_ON_ZERO() and
> BUILD_BUG_ON_NULL() macros by adding parentheses around the bitfield
> widths that begin with a minus sign.
>
> Signed-off-by: Ian Abbott <abbotti@mev.co.uk>

Oh yes, thank you. I've had a few places where I would have liked to
use BUILD_BUG_ON() but avoided it due to the header soup. :)

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> v5: Actually, there was no v1 thru v4.  I called this v5 to match the
> series.
> ---
>  include/linux/bug.h       | 74 +----------------------------------------
>  include/linux/build_bug.h | 84 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 85 insertions(+), 73 deletions(-)
>  create mode 100644 include/linux/build_bug.h
>
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index 483207cb99fb..5d5554c874fd 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -3,6 +3,7 @@
>
>  #include <asm/bug.h>
>  #include <linux/compiler.h>
> +#include <linux/build_bug.h>
>
>  enum bug_trap_type {
>         BUG_TRAP_TYPE_NONE = 0,
> @@ -13,82 +14,9 @@ enum bug_trap_type {
>  struct pt_regs;
>
>  #ifdef __CHECKER__
> -#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
> -#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
> -#define BUILD_BUG_ON_ZERO(e) (0)
> -#define BUILD_BUG_ON_NULL(e) ((void *)0)
> -#define BUILD_BUG_ON_INVALID(e) (0)
> -#define BUILD_BUG_ON_MSG(cond, msg) (0)
> -#define BUILD_BUG_ON(condition) (0)
> -#define BUILD_BUG() (0)
>  #define MAYBE_BUILD_BUG_ON(cond) (0)
>  #else /* __CHECKER__ */
>
> -/* Force a compilation error if a constant expression is not a power of 2 */
> -#define __BUILD_BUG_ON_NOT_POWER_OF_2(n)       \
> -       BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
> -#define BUILD_BUG_ON_NOT_POWER_OF_2(n)                 \
> -       BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
> -
> -/*
> - * Force a compilation error if condition is true, but also produce a
> - * result (of value 0 and type size_t), so the expression can be used
> - * e.g. in a structure initializer (or where-ever else comma expressions
> - * aren't permitted).
> - */
> -#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> -#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:(-!!(e)); }))
> -
> -/*
> - * BUILD_BUG_ON_INVALID() permits the compiler to check the validity of the
> - * expression but avoids the generation of any code, even if that expression
> - * has side-effects.
> - */
> -#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
> -
> -/**
> - * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> - *                   error message.
> - * @condition: the condition which the compiler should know is false.
> - *
> - * See BUILD_BUG_ON for description.
> - */
> -#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> -
> -/**
> - * BUILD_BUG_ON - break compile if a condition is true.
> - * @condition: the condition which the compiler should know is false.
> - *
> - * If you have some code which relies on certain constants being equal, or
> - * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> - * detect if someone changes it.
> - *
> - * The implementation uses gcc's reluctance to create a negative array, but gcc
> - * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
> - * inline functions).  Luckily, in 4.3 they added the "error" function
> - * attribute just for this type of case.  Thus, we use a negative sized array
> - * (should always create an error on gcc versions older than 4.4) and then call
> - * an undefined function with the error attribute (should always create an
> - * error on gcc 4.3 and later).  If for some reason, neither creates a
> - * compile-time error, we'll still have a link-time error, which is harder to
> - * track down.
> - */
> -#ifndef __OPTIMIZE__
> -#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> -#else
> -#define BUILD_BUG_ON(condition) \
> -       BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> -#endif
> -
> -/**
> - * BUILD_BUG - break compile if used.
> - *
> - * If you have some code that you expect the compiler to eliminate at
> - * build time, you should use BUILD_BUG to detect if it is
> - * unexpectedly used.
> - */
> -#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> -
>  #define MAYBE_BUILD_BUG_ON(cond)                       \
>         do {                                            \
>                 if (__builtin_constant_p((cond)))       \
> diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
> new file mode 100644
> index 000000000000..b7d22d60008a
> --- /dev/null
> +++ b/include/linux/build_bug.h
> @@ -0,0 +1,84 @@
> +#ifndef _LINUX_BUILD_BUG_H
> +#define _LINUX_BUILD_BUG_H
> +
> +#include <linux/compiler.h>
> +
> +#ifdef __CHECKER__
> +#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
> +#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
> +#define BUILD_BUG_ON_ZERO(e) (0)
> +#define BUILD_BUG_ON_NULL(e) ((void *)0)
> +#define BUILD_BUG_ON_INVALID(e) (0)
> +#define BUILD_BUG_ON_MSG(cond, msg) (0)
> +#define BUILD_BUG_ON(condition) (0)
> +#define BUILD_BUG() (0)
> +#else /* __CHECKER__ */
> +
> +/* Force a compilation error if a constant expression is not a power of 2 */
> +#define __BUILD_BUG_ON_NOT_POWER_OF_2(n)       \
> +       BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
> +#define BUILD_BUG_ON_NOT_POWER_OF_2(n)                 \
> +       BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
> +
> +/*
> + * Force a compilation error if condition is true, but also produce a
> + * result (of value 0 and type size_t), so the expression can be used
> + * e.g. in a structure initializer (or where-ever else comma expressions
> + * aren't permitted).
> + */
> +#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
> +#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:(-!!(e)); }))
> +
> +/*
> + * BUILD_BUG_ON_INVALID() permits the compiler to check the validity of the
> + * expression but avoids the generation of any code, even if that expression
> + * has side-effects.
> + */
> +#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
> +
> +/**
> + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> + *                   error message.
> + * @condition: the condition which the compiler should know is false.
> + *
> + * See BUILD_BUG_ON for description.
> + */
> +#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> +
> +/**
> + * BUILD_BUG_ON - break compile if a condition is true.
> + * @condition: the condition which the compiler should know is false.
> + *
> + * If you have some code which relies on certain constants being equal, or
> + * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> + * detect if someone changes it.
> + *
> + * The implementation uses gcc's reluctance to create a negative array, but gcc
> + * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
> + * inline functions).  Luckily, in 4.3 they added the "error" function
> + * attribute just for this type of case.  Thus, we use a negative sized array
> + * (should always create an error on gcc versions older than 4.4) and then call
> + * an undefined function with the error attribute (should always create an
> + * error on gcc 4.3 and later).  If for some reason, neither creates a
> + * compile-time error, we'll still have a link-time error, which is harder to
> + * track down.
> + */
> +#ifndef __OPTIMIZE__
> +#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> +#else
> +#define BUILD_BUG_ON(condition) \
> +       BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> +#endif
> +
> +/**
> + * BUILD_BUG - break compile if used.
> + *
> + * If you have some code that you expect the compiler to eliminate at
> + * build time, you should use BUILD_BUG to detect if it is
> + * unexpectedly used.
> + */
> +#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> +
> +#endif /* __CHECKER__ */
> +
> +#endif /* _LINUX_BUILD_BUG_H */
> --
> 2.11.0
>



-- 
Kees Cook
Pixel Security

  parent reply	other threads:[~2017-05-25 18:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-25 12:03 [PATCH v5 0/6] kernel.h: container_of() pointer checking Ian Abbott
2017-05-25 12:03 ` [PATCH v5 1/6] asm-generic/bug.h: declare struct pt_regs; before function prototype Ian Abbott
2017-06-08 14:07   ` Steven Rostedt
2017-06-12 14:13     ` Ian Abbott
2017-06-12 14:15       ` Steven Rostedt
2017-05-25 12:03 ` [PATCH v5 2/6] linux/bug.h: correct formatting of block comment Ian Abbott
2017-05-25 13:58   ` Michal Nazarewicz
2017-05-25 12:03 ` [PATCH v5 3/6] linux/bug.h: correct "(foo*)" should be "(foo *)" Ian Abbott
2017-05-25 13:59   ` Michal Nazarewicz
2017-05-25 12:03 ` [PATCH v5 4/6] linux/bug.h: correct "space required before that '-'" Ian Abbott
2017-05-25 14:01   ` Michal Nazarewicz
2017-05-25 14:02   ` Michal Nazarewicz
2017-05-25 12:03 ` [PATCH v5 5/6] bug: split BUILD_BUG stuff out into <linux/build_bug.h> Ian Abbott
2017-05-25 14:06   ` Michal Nazarewicz
2017-05-25 18:30   ` Kees Cook [this message]
2017-05-25 12:03 ` [PATCH v5 6/6] kernel.h: handle pointers to arrays better in container_of() Ian Abbott
2017-05-25 14:07   ` Michal Nazarewicz
2017-05-25 18:35   ` Kees Cook
2017-05-26 13:57     ` Ian Abbott

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=CAGXu5jKukZxGK_hk77Acq0omtTEnRp-YXF+Y58db5AyZjD5t2Q@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=abbotti@mev.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=glider@google.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mina86@mina86.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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;
as well as URLs for NNTP newsgroup(s).