All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Ian Abbott <abbotti@mev.co.uk>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Cc: 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>,
	Ian Abbott <abbotti@mev.co.uk>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Kees Cook <keescook@chromium.org>,
	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 16:06:20 +0200	[thread overview]
Message-ID: <xa1t1srdhvz7.fsf@mina86.com> (raw)
In-Reply-To: <20170525120316.24473-6-abbotti@mev.co.uk>

On Thu, May 25 2017, Ian Abbott 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>
> 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>

Acked-by: Michal Nazarewicz <mina86@mina86.com>

> ---
> 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 */

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Cc: 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>,
	Ian Abbott <abbotti@mev.co.uk>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Kees Cook <keescook@chromium.org>,
	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 16:06:20 +0200	[thread overview]
Message-ID: <xa1t1srdhvz7.fsf@mina86.com> (raw)
In-Reply-To: <20170525120316.24473-6-abbotti@mev.co.uk>

On Thu, May 25 2017, Ian Abbott 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>
> 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>

Acked-by: Michal Nazarewicz <mina86@mina86.com>

> ---
> 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 */

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: Ian Abbott <abbotti@mev.co.uk>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Cc: 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>,
	Kees Cook <keescook@chromium.org>,
	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 16:06:20 +0200	[thread overview]
Message-ID: <xa1t1srdhvz7.fsf@mina86.com> (raw)
Message-ID: <20170525140620.XIMeIt8UTWzUW3JJ08Jp4Nzarb2drCUMG5Axd9qi6fU@z> (raw)
In-Reply-To: <20170525120316.24473-6-abbotti@mev.co.uk>

On Thu, May 25 2017, Ian Abbott 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>
> 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>

Acked-by: Michal Nazarewicz <mina86@mina86.com>

> ---
> 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 */

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

  reply	other threads:[~2017-05-25 14:06 UTC|newest]

Thread overview: 31+ 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 13:58     ` Michal Nazarewicz
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 13:59     ` Michal Nazarewicz
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:01     ` Michal Nazarewicz
2017-05-25 14:01     ` Michal Nazarewicz
2017-05-25 14:02   ` Michal Nazarewicz
2017-05-25 14:02     ` 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 [this message]
2017-05-25 14:06     ` Michal Nazarewicz
2017-05-25 14:06     ` Michal Nazarewicz
2017-05-25 18:30   ` Kees Cook
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 14:07     ` Michal Nazarewicz
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=xa1t1srdhvz7.fsf@mina86.com \
    --to=mina86@mina86.com \
    --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=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --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 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.