[PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[Jason Uhlenkott]

The ia64 BUG macro deliberately writes to address 0 in order to
trigger a page fault and an Oops.  This won't work if the process has
mapped something into page zero:  We'll just print the "kernel BUG"
message and continue (after having stomped on whatever user memory was
at address 0).

A solution is to write to the guard page in region 5, which is
guaranteed to trigger a page fault.


--- linux-2.4.25.orig/include/asm-ia64/page.h	Wed Feb 18 05:36:32 2004
+++ linux-2.4.25/include/asm-ia64/page.h	Wed Feb 18 13:59:10 2004
@@ -120,7 +120,7 @@
 #define is_invalid_hugepage_range(addr, len) 0
 #endif
 
-#define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); *(int *)0=0; } while (0)
+#define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); *(int *)0xa000000000000000=0; } while (0)
 #define PAGE_BUG(page) do { BUG(); } while (0)
 
 static __inline__ int

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[David Mosberger]

>>>>> On Wed, 18 Feb 2004 14:13:03 -0800, Jason Uhlenkott <jasonuhl@sgi.com> said:

  Jason> The ia64 BUG macro deliberately writes to address 0 in order to
  Jason> trigger a page fault and an Oops.  This won't work if the process has
  Jason> mapped something into page zero:  We'll just print the "kernel BUG"
  Jason> message and continue (after having stomped on whatever user memory was
  Jason> at address 0).

  Jason> A solution is to write to the guard page in region 5, which is
  Jason> guaranteed to trigger a page fault.

The 2.6 kernel uses __builtin_trap(), which is even better (when available).

	--david

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[Bjorn Helgaas]

On Wednesday 18 February 2004 6:14 pm, David Mosberger wrote:
> >>>>> On Wed, 18 Feb 2004 14:13:03 -0800, Jason Uhlenkott <jasonuhl@sgi.com> said:
> 
>   Jason> The ia64 BUG macro deliberately writes to address 0 in order to
>   Jason> trigger a page fault and an Oops.  This won't work if the process has
>   Jason> mapped something into page zero:  We'll just print the "kernel BUG"
>   Jason> message and continue (after having stomped on whatever user memory was
>   Jason> at address 0).
> 
>   Jason> A solution is to write to the guard page in region 5, which is
>   Jason> guaranteed to trigger a page fault.
> 
> The 2.6 kernel uses __builtin_trap(), which is even better (when available).

How about the following?  I like the idea of using the guard page
instead of address 0, but I sort of hate to add another magic number
(though I guess you could argue that "0" is almost as magic as
"0xa000000000000000").  And I would think most people would be
using gcc 3.x or better by now.

=== include/asm-ia64/page.h 1.9 vs edited ==--- 1.9/include/asm-ia64/page.h	Tue Jan 20 13:44:48 2004
+++ edited/include/asm-ia64/page.h	Thu Mar  4 16:20:00 2004
@@ -120,7 +120,13 @@
 #define is_invalid_hugepage_range(addr, len) 0
 #endif
 
-#define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); *(int *)0=0; } while (0)
+#if (__GNUC__ > 3) || (__GNUC__ = 3 && __GNUC_MINOR__ >= 1)
+# define ia64_abort()	__builtin_trap()
+#else
+# define ia64_abort()	(*(volatile int *) 0 = 0)
+#endif
+
+#define BUG() do { printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); ia64_abort(); } while (0)
 #define PAGE_BUG(page) do { BUG(); } while (0)
 
 static __inline__ int

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[Keith Owens]

On Thu, 4 Mar 2004 16:25:00 -0700, 
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>How about the following?  I like the idea of using the guard page
>instead of address 0, but I sort of hate to add another magic number
>(though I guess you could argue that "0" is almost as magic as
>"0xa000000000000000").

Why not use 'break 0' for gcc < 3.1?  No need to worry about which
pages are protected.

        switch (break_num) {
              case 0: /* unknown error (used by GCC for __builtin_abort()) */
                die_if_kernel("bugcheck!", regs, break_num);

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[Bjorn Helgaas]

On Thursday 04 March 2004 4:41 pm, Keith Owens wrote:
> Why not use 'break 0' for gcc < 3.1?  No need to worry about which
> pages are protected.
> 
>         switch (break_num) {
>               case 0: /* unknown error (used by GCC for __builtin_abort()) */
>                 die_if_kernel("bugcheck!", regs, break_num);

Sounds reasonable to me, but I'm too chicken.  Propose a patch and
get David to take it, and I'll put it in 2.4.

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[David Mosberger]

>>>>> On Thu, 4 Mar 2004 16:57:43 -0700, Bjorn Helgaas <bjorn.helgaas@hp.com> said:

  Bjorn> On Thursday 04 March 2004 4:41 pm, Keith Owens wrote:

  >> Why not use 'break 0' for gcc < 3.1?  No need to worry about
  >> which pages are protected.

  >> switch (break_num) { case 0: /* unknown error (used by GCC for
  >> __builtin_abort()) */ die_if_kernel("bugcheck!", regs,
  >> break_num);

  Bjorn> Sounds reasonable to me, but I'm too chicken.  Propose a
  Bjorn> patch and get David to take it, and I'll put it in 2.4.

I don't think it's worth changing (2.9x is out for 2.6 anyhow, and I
doubt anyone is using GCC 3.0 for real work; if you do, you're
probably in lots of trouble for other reasons!).  Besides, one
disadvantage of using "break 0" is that it will make Ski stop
immediately, which isn't what you want.

	--david

Re: [PATCH] 2.4.25: BUG(): Use guard page instead of page 0

[David Mosberger]

>>>>> On Thu, 4 Mar 2004 16:05:31 -0800, David Mosberger <davidm@linux.hpl.hp.com> said:

  David> I don't think it's worth changing (2.9x is out for 2.6
  David> anyhow, and I doubt anyone is using GCC 3.0 for real work; if
  David> you do, you're probably in lots of trouble for other
  David> reasons!).  Besides, one disadvantage of using "break 0" is
  David> that it will make Ski stop immediately, which isn't what you
  David> want.

Never mind.  The Ski argument is BS of course... (since that's what
__builtin_trap() uses... ;-)

	--david