[PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[David Daney]

From: David Daney <david.daney@cavium.com>


For v3:

No code changes.

Fix comment text in kernel.h to correctly reflect the name
BUILD_BUG().  Updated patch chanegelogs with slightly better
descriptions and some Acked-by: headers.

Andrew, since you have version 2 in you tree currently, can you
replace those patches with this version instead?

Thanks,
David Daney

>From v2:

   As suggested by 'DM', call the macro BUILD_BUG() instead of
   BUILD_BUG_ON_USED().  Linus seemed satisfied with this, so if it
   still looks good, can we put it in some linux-next tree (Perhaps
   Andrew Morton's) to cook for a while?

   The second patch now covers linux/huge_mm.h too.

>From v1:

   After some, perhaps justified, reluctance to merge dummy
   symbol definitions containing BUG() into header files, I propose
   these patches instead.

   We define a new compile time assertion BUILD_BUG_ON_USED() that can
   be used in places were we expect the compiler's dead code
   elimination to get rid of code.  This happens mostly in code
   dealing with huge pages, but in other places as well.

   The first patch adds BUILD_BUG_ON_USED(), the second gets rid of
   one of the main abusers of BUG().

David Daney (2):
  kernel.h: Add BUILD_BUG() macro.
  hugetlb: Replace BUG() with BUILD_BUG() for dummy definitions.

 include/linux/compiler-gcc4.h |    1 +
 include/linux/compiler.h      |    4 +++-
 include/linux/huge_mm.h       |    8 ++++----
 include/linux/hugetlb.h       |   14 +++++++-------
 include/linux/kernel.h        |   16 ++++++++++++++++
 5 files changed, 31 insertions(+), 12 deletions(-)

-- 
1.7.2.3

[PATCH v3 1/2] kernel.h: Add BUILD_BUG() macro.

[David Daney]

From: David Daney <david.daney@cavium.com>

We can place this in definitions that we expect the compiler to remove
by dead code elimination.  If this assertion fails, we get a nice
error message at build time.

The GCC function attribute error("message") was added in version 4.3,
so we define a new macro __linktime_error(message) to expand to this
for GCC-4.3 and later.  This will give us an error diagnostic from the
compiler on the line that fails.  For other compilers
__linktime_error(message) expands to nothing, and we have to be
content with a link time error, but at least we will still get a build
error.

BUILD_BUG() expands to the undefined function __build_bug_failed() and
will fail at link time if the compiler ever emits code for it.  On
GCC-4.3 and later, attribute((error())) is used so that the failure
will be noted at compile time instead.

Acked-by: David Howells <dhowells@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
 include/linux/compiler-gcc4.h |    1 +
 include/linux/compiler.h      |    4 +++-
 include/linux/kernel.h        |   16 ++++++++++++++++
 3 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index dfadc96..2f40791 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -29,6 +29,7 @@
    the kernel context */
 #define __cold			__attribute__((__cold__))
 
+#define __linktime_error(message) __attribute__((__error__(message)))
 
 #if __GNUC_MINOR__ >= 5
 /*
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 320d6c9..4a24354 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -293,7 +293,9 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
 #ifndef __compiletime_error
 # define __compiletime_error(message)
 #endif
-
+#ifndef __linktime_error
+# define __linktime_error(message)
+#endif
 /*
  * Prevent the compiler from merging or refetching accesses.  The compiler
  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index b93c66e..723ef1b 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -666,6 +666,7 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
 #define BUILD_BUG_ON_ZERO(e) (0)
 #define BUILD_BUG_ON_NULL(e) ((void*)0)
 #define BUILD_BUG_ON(condition)
+#define BUILD_BUG() (0)
 #else /* __CHECKER__ */
 
 /* Force a compilation error if a constant expression is not a power of 2 */
@@ -704,6 +705,21 @@ extern int __build_bug_on_failed;
 		if (condition) __build_bug_on_failed = 1;	\
 	} while(0)
 #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()						\
+	do {							\
+		extern void __build_bug_failed(void)		\
+			__linktime_error("BUILD_BUG failed");	\
+		__build_bug_failed();				\
+	} while (0)
+
 #endif	/* __CHECKER__ */
 
 /* Trap pasters of __FUNCTION__ at compile-time */
-- 
1.7.2.3

[PATCH] mips: remove custom BUILD_BUG()

[Eric Dumazet]

Commit 1399ff86f2a2b (kernel.h: add BUILD_BUG() macro) broke mips build

In file included from /opt/src/linux/arch/mips/include/asm/io.h:16:0,
                 from /opt/src/linux/arch/mips/include/asm/page.h:54,
                 from include/linux/serial.h:16,
                 from include/linux/serial_core.h:23,
                 from include/linux/serial_8250.h:14,
                 from arch/mips/mti-malta/malta-platform.c:25:
include/linux/kernel.h:717:0: error: "BUILD_BUG" redefined [-Werror]
/opt/src/linux/arch/mips/include/asm/page.h:43:0: note: this is the
location of the previous definition
cc1: all warnings being treated as errors

Remove the conflicting mips macro.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Ralf Baechle <ralf@linux-mips.org>
---
 arch/mips/include/asm/page.h |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index d417909..da9bd7d 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -39,9 +39,6 @@
 #define HPAGE_MASK	(~(HPAGE_SIZE - 1))
 #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
 #else /* !CONFIG_HUGETLB_PAGE */
-# ifndef BUILD_BUG
-#  define BUILD_BUG() do { extern void __build_bug(void); __build_bug(); } while (0)
-# endif
 #define HPAGE_SHIFT	({BUILD_BUG(); 0; })
 #define HPAGE_SIZE	({BUILD_BUG(); 0; })
 #define HPAGE_MASK	({BUILD_BUG(); 0; })

Re: [PATCH] mips: remove custom BUILD_BUG()

[Ralf Baechle]

On Tue, Jan 17, 2012 at 06:52:52AM +0100, Eric Dumazet wrote:
> Date:   Tue, 17 Jan 2012 06:52:52 +0100
> From: Eric Dumazet <eric.dumazet@gmail.com>
> To: David Daney <ddaney.cavm@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>, ralf@linux-mips.org,
>  linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Linus Torvalds
>  <torvalds@linux-foundation.org>, David Rientjes <rientjes@google.com>, DM
>  <dm.n9107@gmail.com>, David Howells <dhowells@redhat.com>, David Daney
>  <david.daney@cavium.com>
> Subject: [PATCH] mips: remove custom BUILD_BUG()
> Content-Type: text/plain; charset="UTF-8"
> 
> Commit 1399ff86f2a2b (kernel.h: add BUILD_BUG() macro) broke mips build
> 
> In file included from /opt/src/linux/arch/mips/include/asm/io.h:16:0,
>                  from /opt/src/linux/arch/mips/include/asm/page.h:54,
>                  from include/linux/serial.h:16,
>                  from include/linux/serial_core.h:23,
>                  from include/linux/serial_8250.h:14,
>                  from arch/mips/mti-malta/malta-platform.c:25:
> include/linux/kernel.h:717:0: error: "BUILD_BUG" redefined [-Werror]
> /opt/src/linux/arch/mips/include/asm/page.h:43:0: note: this is the
> location of the previous definition
> cc1: all warnings being treated as errors
> 
> Remove the conflicting mips macro.

See 63e9c4fd1c86e894e62aa3737427163d5fb01056 [MIPS: Remove temporary kludge
from <asm/page.h>] in linux-next.

  Ralf

Re: [PATCH] mips: remove custom BUILD_BUG()

[Eric Dumazet]

Le mardi 17 janvier 2012 à 09:28 +0100, Ralf Baechle a écrit :

> See 63e9c4fd1c86e894e62aa3737427163d5fb01056 [MIPS: Remove temporary kludge
> from <asm/page.h>] in linux-next.
> 

Good, thanks !

[PATCH v3 2/2] hugetlb: Replace BUG() with BUILD_BUG() for dummy definitions.

[David Daney]

From: David Daney <david.daney@cavium.com>

The files linux/hugetlb.h and linux/huge_mm.h have several places
where dummy symbols were defined so that the main source code would
contain fewer:

    #ifdef CONFIG_HUGETLBFS

or

    #ifdef CONFIG_TRANSPARENT_HUGEPAGE

If there were any misuse of these symbols, the only symptom would be
an OOPS at runtime.  Change the BUG() to BUILD_BUG() to catch
any such abuse at compile time instead.

Acked-by: David Howells <dhowells@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
 include/linux/huge_mm.h |    8 ++++----
 include/linux/hugetlb.h |   14 +++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a9ace9c..33e47d8 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -145,10 +145,10 @@ static inline struct page *compound_trans_head(struct page *page)
 	}
 	return page;
 }
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-#define HPAGE_PMD_SHIFT ({ BUG(); 0; })
-#define HPAGE_PMD_MASK ({ BUG(); 0; })
-#define HPAGE_PMD_SIZE ({ BUG(); 0; })
+#else /* !CONFIG_TRANSPARENT_HUGEPAGE */
+#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
+#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
+#define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
 
 #define hpage_nr_pages(x) 1
 
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index d9d6c86..1289937 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -85,11 +85,11 @@ static inline unsigned long hugetlb_total_pages(void)
 	return 0;
 }
 
-#define follow_hugetlb_page(m,v,p,vs,a,b,i,w)	({ BUG(); 0; })
+#define follow_hugetlb_page(m,v,p,vs,a,b,i,w)	({ BUILD_BUG(); 0; })
 #define follow_huge_addr(mm, addr, write)	ERR_PTR(-EINVAL)
-#define copy_hugetlb_page_range(src, dst, vma)	({ BUG(); 0; })
-#define hugetlb_prefault(mapping, vma)		({ BUG(); 0; })
-#define unmap_hugepage_range(vma, start, end, page)	BUG()
+#define copy_hugetlb_page_range(src, dst, vma)	({ BUILD_BUG(); 0; })
+#define hugetlb_prefault(mapping, vma)		({ BUILD_BUG(); 0; })
+#define unmap_hugepage_range(vma, start, end, page)	BUILD_BUG()
 static inline void hugetlb_report_meminfo(struct seq_file *m)
 {
 }
@@ -100,8 +100,8 @@ static inline void hugetlb_report_meminfo(struct seq_file *m)
 #define pmd_huge(x)	0
 #define pud_huge(x)	0
 #define is_hugepage_only_range(mm, addr, len)	0
-#define hugetlb_free_pgd_range(tlb, addr, end, floor, ceiling) ({BUG(); 0; })
-#define hugetlb_fault(mm, vma, addr, flags)	({ BUG(); 0; })
+#define hugetlb_free_pgd_range(tlb, addr, end, f, c) ({BUILD_BUG(); 0; })
+#define hugetlb_fault(mm, vma, addr, flags)	({ BUILD_BUG(); 0; })
 #define huge_pte_offset(mm, address)	0
 #define dequeue_hwpoisoned_huge_page(page)	0
 static inline void copy_huge_page(struct page *dst, struct page *src)
@@ -186,7 +186,7 @@ static inline void set_file_hugepages(struct file *file)
 #else /* !CONFIG_HUGETLBFS */
 
 #define is_file_hugepages(file)			0
-#define set_file_hugepages(file)		BUG()
+#define set_file_hugepages(file)		BUILD_BUG()
 static inline struct file *hugetlb_file_setup(const char *name, size_t size,
 		vm_flags_t acctflag, struct user_struct **user, int creat_flags)
 {
-- 
1.7.2.3

Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[Linus Torvalds]

Btw, would it possibly make sense to make the string more useful?

For example using __FILE__ and __LINE__, or possibly letting the user
of the BUILD_BUG() give a string ("Using HMASK without
CONFIG_HUGEPAGE").

Whatever. It's bikeshedding - what would probably be more important
would be to get this into linux-next so that we find out whether there
are any compile issues with it on other platforms or compiler
versions.

                  Linus

Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[David Daney]

On 11/23/2011 03:57 PM, Linus Torvalds wrote:
> Btw, would it possibly make sense to make the string more useful?
>
> For example using __FILE__ and __LINE__, or possibly letting the user
> of the BUILD_BUG() give a string ("Using HMASK without
> CONFIG_HUGEPAGE").

We thought about doing that, but without doing some complex preprocessor 
fu, the GCC attribute ((error())) thing doesn't do what we want.

It appears that if more than a single instance of the construct is used 
in a compilation unit, the string emitted by the compiler for any of the 
violations will be the last string encountered.

So if you did something like:

.
.
.
Line 99:  BUILD_BUG("You failed on line 99");
.
.
.
.
Line 666: BUILD_BUG("You failed on line 666");
.
.
.

The message emitted for a failure at line 99 would be "You failed on 
line 666".  Which is probably worse than no message at all.

It may be possible to do something like:

#define _LINENAME_CONCAT( _name_, _line_ ) _name_##_line_
#define _LINENAME(_name_, _line_) _LINENAME_CONCAT(_name_,_line_)

#define _BUILD_BUG(MSG,FUBAR)		\
do {					\
   extern void FUBAR (void)		\
      __linktime_error("BUILD_BUG failed: " MSG); \
   FUBAR ();				\
} while (0)

#define BUILD_BUG(M,A) _BUILD_BUG(M, _LINENAME(__build_bug_failed,__LINE__))

But it didn't seem worth it.

>
> Whatever. It's bikeshedding - what would probably be more important
> would be to get this into linux-next so that we find out whether there
> are any compile issues with it on other platforms or compiler
> versions.
>
>                    Linus
>

Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[David Howells]

David Daney <ddaney.cavm@gmail.com> wrote:

> We thought about doing that, but without doing some complex preprocessor fu,
> the GCC attribute ((error())) thing doesn't do what we want.
> 
> It appears that if more than a single instance of the construct is used in a
> compilation unit, the string emitted by the compiler for any of the violations
> will be the last string encountered.

Have you tried asking the gcc folks if this is likely to get fixed soon?

David

Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[Linus Torvalds]

On Thu, Nov 24, 2011 at 2:24 AM, David Howells <dhowells@redhat.com> wrote:
>
> Have you tried asking the gcc folks if this is likely to get fixed soon?

I actually don't think it's a bug. The error message is associated
with the function declaration symbol, so it actually makes sense that
there can be only one error message per callee - not per caller.

Using "__LINE__" to then create fairly unique symbols (modulo
#include, of course) gets around it in a pretty natural way as ddaney
said, so if we care enough.  I don't think it's a big issue (as
mentioned, I'd worry more about us making sure it's reliable enough to
be used - we've had gcc sometimes fail to compile things out just
because some optimization was not working well enough).

               Linus

Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used.

[David Daney]

On 11/24/2011 10:31 AM, Linus Torvalds wrote:
> On Thu, Nov 24, 2011 at 2:24 AM, David Howells<dhowells@redhat.com>  wrote:
>>
>> Have you tried asking the gcc folks if this is likely to get fixed soon?
>
> I actually don't think it's a bug. The error message is associated
> with the function declaration symbol, so it actually makes sense that
> there can be only one error message per callee - not per caller.
>

Yes, that is correct.

> Using "__LINE__" to then create fairly unique symbols (modulo
> #include, of course) gets around it in a pretty natural way as ddaney
> said, so if we care enough.  I don't think it's a big issue (as
> mentioned, I'd worry more about us making sure it's reliable enough to
> be used - we've had gcc sometimes fail to compile things out just
> because some optimization was not working well enough).
>

Since these are *build* bugs, they are of a different nature than the 
*runtime* variety.  They will never be seen at random times by someone 
running the kernel, so making it easier to determine their cause is less 
important.  Really, I would expect it to never really be an issue.

We will always know which file is the culprit.  Finding the line number 
can be done like this:

objdump -r $file | grep build_bug | addr2line -e $file

David Daney