[PATCH] conditionalize some boring buffer_head checks

[PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]


These checks are executed billions of times per day, with no stack dump 
bug reports sent to lkml.  Arguably, they will only trigger on buggy 
filesystems (programmer error), and thus IMO shouldn't even be executed 
in a non-debug kernel.

Even though BUG_ON() includes unlikely(), I think this patch -- or 
something like it -- is preferable.  The buffer_error() checks aren't 
even marked unlikely().

This is a micro-optimization on a key kernel fast path.



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 849 bytes --]

===== fs/buffer.c 1.237 vs edited =====
--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
+++ edited/fs/buffer.c	Wed Apr 14 03:39:15 2004
@@ -2688,6 +2688,7 @@
 {
 	struct bio *bio;
 
+#ifdef BH_DEBUG
 	BUG_ON(!buffer_locked(bh));
 	BUG_ON(!buffer_mapped(bh));
 	BUG_ON(!bh->b_end_io);
@@ -2698,6 +2699,7 @@
 		buffer_error();
 	if (rw == READ && buffer_dirty(bh))
 		buffer_error();
+#endif
 
 	/* Only clear out a write error when rewriting */
 	if (test_set_buffer_req(bh) && rw == WRITE)
===== include/linux/buffer_head.h 1.47 vs edited =====
--- 1.47/include/linux/buffer_head.h	Wed Apr 14 03:18:09 2004
+++ edited/include/linux/buffer_head.h	Wed Apr 14 03:39:31 2004
@@ -13,6 +13,8 @@
 #include <linux/wait.h>
 #include <asm/atomic.h>
 
+#undef BH_DEBUG
+
 enum bh_state_bits {
 	BH_Uptodate,	/* Contains valid data */
 	BH_Dirty,	/* Is dirty */

Re: [PATCH] conditionalize some boring buffer_head checks

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> 
> These checks are executed billions of times per day, with no stack dump 
> bug reports sent to lkml.  Arguably, they will only trigger on buggy 
> filesystems (programmer error), and thus IMO shouldn't even be executed 
> in a non-debug kernel.
> 
> Even though BUG_ON() includes unlikely(), I think this patch -- or 
> something like it -- is preferable.  The buffer_error() checks aren't 
> even marked unlikely().
> 
> This is a micro-optimization on a key kernel fast path.
> 

buffer_error() was always supposed to be temporary.  Once per month someone
reports the one in __find_get_block_slow(), but that's all.  The only
reason for keeping it around is as a debug aid to filesystem developers.

We could make it a no-op if !CONFIG_BUFFER_DEBUG.

Re: [PATCH] conditionalize some boring buffer_head checks

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
>  buffer_error() was always supposed to be temporary.  Once per month someone
>  reports the one in __find_get_block_slow(), but that's all.  The only
>  reason for keeping it around is as a debug aid to filesystem developers.
> 
>  We could make it a no-op if !CONFIG_BUFFER_DEBUG.

But even if we do that, the compiler cannot optimise away things like:

	if (atomic_read(&bh->b_count) == 0 &&
			!PageLocked(bh->b_page) &&
			!PageWriteback(bh->b_page))
		do {} while (0);

so if it offends you, go kill the thing outright.

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> 
>> buffer_error() was always supposed to be temporary.  Once per month someone
>> reports the one in __find_get_block_slow(), but that's all.  The only
>> reason for keeping it around is as a debug aid to filesystem developers.
>>
>> We could make it a no-op if !CONFIG_BUFFER_DEBUG.
> 
> 
> But even if we do that, the compiler cannot optimise away things like:
> 
> 	if (atomic_read(&bh->b_count) == 0 &&
> 			!PageLocked(bh->b_page) &&
> 			!PageWriteback(bh->b_page))
> 		do {} while (0);

Nod.


> so if it offends you, go kill the thing outright.

If you like config variables, here's a second patch (untested but should 
be obvious).  As a side note, we need a Kconfig for generic debugging 
options...

I would rather not kill the code in submit_bh() outright, just disable 
it for non-filesystem developers.

For me, buffer_error() definition is secondary to disabling these 
checks-that-noone-hits in the submit_bh() fast path.

	Jeff



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 9635 bytes --]

===== arch/alpha/Kconfig 1.36 vs edited =====
--- 1.36/arch/alpha/Kconfig	Sat Mar 20 13:29:54 2004
+++ edited/arch/alpha/Kconfig	Wed Apr 14 04:03:41 2004
@@ -690,6 +690,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/arm/Kconfig 1.53 vs edited =====
--- 1.53/arch/arm/Kconfig	Thu Apr  8 15:41:09 2004
+++ edited/arch/arm/Kconfig	Wed Apr 14 04:03:58 2004
@@ -724,6 +724,13 @@
 	  you are concerned with the code size or don't want to see these
 	  messages.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 # These options are only for real kernel hackers who want to get their hands dirty. 
 config DEBUG_LL
 	bool "Kernel low-level debugging functions"
===== arch/arm26/Kconfig 1.11 vs edited =====
--- 1.11/arch/arm26/Kconfig	Mon Mar  1 10:52:18 2004
+++ edited/arch/arm26/Kconfig	Wed Apr 14 04:03:47 2004
@@ -316,6 +316,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 # These options are only for real kernel hackers who want to get their hands dirty. 
 config DEBUG_LL
 	bool "Kernel low-level debugging functions"
===== arch/i386/Kconfig 1.116 vs edited =====
--- 1.116/arch/i386/Kconfig	Mon Apr 12 13:54:45 2004
+++ edited/arch/i386/Kconfig	Wed Apr 14 04:04:34 2004
@@ -1286,6 +1286,13 @@
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.	
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
 	bool "Compile the kernel with frame pointers"
 	help
===== arch/ia64/Kconfig 1.69 vs edited =====
--- 1.69/arch/ia64/Kconfig	Mon Apr 12 21:50:46 2004
+++ edited/arch/ia64/Kconfig	Wed Apr 14 04:04:46 2004
@@ -503,6 +503,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config SYSVIPC_COMPAT
 	bool
 	depends on COMPAT && SYSVIPC
===== arch/m68k/Kconfig 1.31 vs edited =====
--- 1.31/arch/m68k/Kconfig	Thu Feb 26 06:25:58 2004
+++ edited/arch/m68k/Kconfig	Wed Apr 14 04:04:50 2004
@@ -688,6 +688,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/mips/Kconfig 1.24 vs edited =====
--- 1.24/arch/mips/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/mips/Kconfig	Wed Apr 14 04:05:05 2004
@@ -1253,6 +1253,13 @@
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config RTC_DS1742
 	bool "DS1742 BRAM/RTC support"
 	depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927
===== arch/parisc/Kconfig 1.28 vs edited =====
--- 1.28/arch/parisc/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/parisc/Kconfig	Wed Apr 14 04:05:10 2004
@@ -222,6 +222,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/ppc/Kconfig 1.57 vs edited =====
--- 1.57/arch/ppc/Kconfig	Tue Mar 30 10:39:41 2004
+++ edited/arch/ppc/Kconfig	Wed Apr 14 04:05:26 2004
@@ -1209,6 +1209,13 @@
 	  debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config BOOTX_TEXT
 	bool "Support for early boot text console (BootX or OpenFirmware only)"
 	depends PPC_OF
===== arch/ppc64/Kconfig 1.52 vs edited =====
--- 1.52/arch/ppc64/Kconfig	Mon Apr 12 13:54:05 2004
+++ edited/arch/ppc64/Kconfig	Wed Apr 14 04:05:16 2004
@@ -395,6 +395,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/s390/Kconfig 1.25 vs edited =====
--- 1.25/arch/s390/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/s390/Kconfig	Wed Apr 14 04:05:32 2004
@@ -397,6 +397,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config DEBUG_SPINLOCK_SLEEP
 	bool "Sleep-inside-spinlock checking"
 	help
===== arch/sparc/Kconfig 1.28 vs edited =====
--- 1.28/arch/sparc/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/sparc/Kconfig	Wed Apr 14 04:06:04 2004
@@ -448,6 +448,13 @@
 	  of the BUG call as well as the EIP and oops trace.  This aids
 	  debugging but costs about 70-100K of memory.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/sparc64/Kconfig 1.50 vs edited =====
--- 1.50/arch/sparc64/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/sparc64/Kconfig	Wed Apr 14 04:05:51 2004
@@ -679,6 +679,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config STACK_DEBUG
 	depends on DEBUG_KERNEL
 	bool "Stack Overflow Detection Support"
===== arch/um/Kconfig 1.14 vs edited =====
--- 1.14/arch/um/Kconfig	Mon Apr 12 13:53:57 2004
+++ edited/arch/um/Kconfig	Wed Apr 14 04:06:09 2004
@@ -233,6 +233,13 @@
         If you're truly short on disk space or don't expect to report any
         bugs back to the UML developers, say N, otherwise say Y.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
 	bool
 	default y if DEBUG_INFO
===== arch/v850/Kconfig 1.21 vs edited =====
--- 1.21/arch/v850/Kconfig	Mon Feb 16 19:42:32 2004
+++ edited/arch/v850/Kconfig	Wed Apr 14 04:06:12 2004
@@ -320,6 +320,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config MAGIC_SYSRQ
 	bool "Magic SysRq key"
 	depends on DEBUG_KERNEL
===== arch/x86_64/Kconfig 1.47 vs edited =====
--- 1.47/arch/x86_64/Kconfig	Mon Apr 12 13:53:56 2004
+++ edited/arch/x86_64/Kconfig	Wed Apr 14 04:06:16 2004
@@ -471,6 +471,13 @@
 	  Please note that this option requires new binutils.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        help
===== fs/buffer.c 1.237 vs edited =====
--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
+++ edited/fs/buffer.c	Wed Apr 14 04:06:40 2004
@@ -2688,6 +2688,7 @@
 {
 	struct bio *bio;
 
+#ifdef CONFIG_DEBUG_BUFFERS
 	BUG_ON(!buffer_locked(bh));
 	BUG_ON(!buffer_mapped(bh));
 	BUG_ON(!bh->b_end_io);
@@ -2698,6 +2699,7 @@
 		buffer_error();
 	if (rw == READ && buffer_dirty(bh))
 		buffer_error();
+#endif
 
 	/* Only clear out a write error when rewriting */
 	if (test_set_buffer_req(bh) && rw == WRITE)

Re: [PATCH] conditionalize some boring buffer_head checks

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> I would rather not kill the code in submit_bh() outright, just disable 
>  it for non-filesystem developers.

submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called
more often, possibly others.  Kill!

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>I would rather not kill the code in submit_bh() outright, just disable 
>> it for non-filesystem developers.
> 
> 
> submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called

Ah, indeed.


> more often, possibly others.  Kill!

Overkill?  (attached)  I didn't mess with the BUG_ON's in submit_bh this 
time, just buffer_error() stuff.

	Jeff



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 7997 bytes --]

===== fs/buffer.c 1.237 vs edited =====
--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
+++ edited/fs/buffer.c	Wed Apr 14 04:32:02 2004
@@ -51,25 +51,6 @@
 	wait_queue_head_t wqh;
 } ____cacheline_aligned_in_smp bh_wait_queue_heads[1<<BH_WAIT_TABLE_ORDER];
 
-/*
- * Debug/devel support stuff
- */
-
-void __buffer_error(char *file, int line)
-{
-	static int enough;
-
-	if (enough > 10)
-		return;
-	enough++;
-	printk("buffer layer error at %s:%d\n", file, line);
-#ifndef CONFIG_KALLSYMS
-	printk("Pass this trace through ksymoops for reporting\n");
-#endif
-	dump_stack();
-}
-EXPORT_SYMBOL(__buffer_error);
-
 inline void
 init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private)
 {
@@ -99,17 +80,6 @@
 
 void fastcall unlock_buffer(struct buffer_head *bh)
 {
-	/*
-	 * unlock_buffer against a zero-count bh is a bug, if the page
-	 * is not locked.  Because then nothing protects the buffer's
-	 * waitqueue, which is used here. (Well.  Other locked buffers
-	 * against the page will pin it.  But complain anyway).
-	 */
-	if (atomic_read(&bh->b_count) == 0 &&
-			!PageLocked(bh->b_page) &&
-			!PageWriteback(bh->b_page))
-		buffer_error();
-
 	clear_buffer_locked(bh);
 	smp_mb__after_clear_bit();
 	wake_up_buffer(bh);
@@ -125,10 +95,6 @@
 	wait_queue_head_t *wqh = bh_waitq_head(bh);
 	DEFINE_WAIT(wait);
 
-	if (atomic_read(&bh->b_count) == 0 &&
-			(!bh->b_page || !PageLocked(bh->b_page)))
-		buffer_error();
-
 	do {
 		prepare_to_wait(wqh, &wait, TASK_UNINTERRUPTIBLE);
 		if (buffer_locked(bh)) {
@@ -146,8 +112,6 @@
 static void
 __set_page_buffers(struct page *page, struct buffer_head *head)
 {
-	if (page_has_buffers(page))
-		buffer_error();
 	page_cache_get(page);
 	SetPagePrivate(page);
 	page->private = (unsigned long)head;
@@ -433,7 +397,8 @@
 		}
 		bh = bh->b_this_page;
 	} while (bh != head);
-	buffer_error();
+
+	BUG();
 	printk("block=%llu, b_blocknr=%llu\n",
 		(unsigned long long)block, (unsigned long long)bh->b_blocknr);
 	printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
@@ -847,10 +812,7 @@
 		struct buffer_head *bh = head;
 
 		do {
-			if (buffer_uptodate(bh))
-				set_buffer_dirty(bh);
-			else
-				buffer_error();
+			set_buffer_dirty(bh);
 			bh = bh->b_this_page;
 		} while (bh != head);
 	}
@@ -1151,7 +1113,7 @@
 	return page;
 
 failed:
-	buffer_error();
+	BUG();
 	unlock_page(page);
 	page_cache_release(page);
 	return NULL;
@@ -1247,8 +1209,6 @@
  */
 void fastcall mark_buffer_dirty(struct buffer_head *bh)
 {
-	if (!buffer_uptodate(bh))
-		buffer_error();
 	if (!buffer_dirty(bh) && !test_set_buffer_dirty(bh))
 		__set_page_dirty_nobuffers(bh->b_page);
 }
@@ -1267,7 +1227,7 @@
 		return;
 	}
 	printk(KERN_ERR "VFS: brelse: Trying to free free buffer\n");
-	buffer_error();		/* For the stack backtrace */
+	BUG();
 }
 
 /*
@@ -1294,8 +1254,6 @@
 		unlock_buffer(bh);
 		return bh;
 	} else {
-		if (buffer_dirty(bh))
-			buffer_error();
 		get_bh(bh);
 		bh->b_end_io = end_buffer_read_sync;
 		submit_bh(READ, bh);
@@ -1737,8 +1695,6 @@
 	last_block = (i_size_read(inode) - 1) >> inode->i_blkbits;
 
 	if (!page_has_buffers(page)) {
-		if (!PageUptodate(page))
-			buffer_error();
 		create_empty_buffers(page, 1 << inode->i_blkbits,
 					(1 << BH_Dirty)|(1 << BH_Uptodate));
 	}
@@ -1777,8 +1733,6 @@
 			clear_buffer_dirty(bh);
 			set_buffer_uptodate(bh);
 		} else if (!buffer_mapped(bh) && buffer_dirty(bh)) {
-			if (buffer_new(bh))
-				buffer_error();
 			err = get_block(inode, block, bh, 1);
 			if (err)
 				goto recover;
@@ -1811,8 +1765,6 @@
 			continue;
 		}
 		if (test_clear_buffer_dirty(bh)) {
-			if (!buffer_uptodate(bh))
-				buffer_error();
 			mark_buffer_async_write(bh);
 		} else {
 			unlock_buffer(bh);
@@ -1942,8 +1894,6 @@
 				unmap_underlying_metadata(bh->b_bdev,
 							bh->b_blocknr);
 				if (PageUptodate(page)) {
-					if (!buffer_mapped(bh))
-						buffer_error();
 					set_buffer_uptodate(bh);
 					continue;
 				}
@@ -2001,8 +1951,6 @@
 			void *kaddr;
 
 			clear_buffer_new(bh);
-			if (buffer_uptodate(bh))
-				buffer_error();
 			kaddr = kmap_atomic(page, KM_USER0);
 			memset(kaddr+block_start, 0, bh->b_size);
 			kunmap_atomic(kaddr, KM_USER0);
@@ -2068,8 +2016,6 @@
 
 	if (!PageLocked(page))
 		PAGE_BUG(page);
-	if (PageUptodate(page))
-		buffer_error();
 	blocksize = 1 << inode->i_blkbits;
 	if (!page_has_buffers(page))
 		create_empty_buffers(page, blocksize, 0);
@@ -2692,13 +2638,6 @@
 	BUG_ON(!buffer_mapped(bh));
 	BUG_ON(!bh->b_end_io);
 
-	if ((rw == READ || rw == READA) && buffer_uptodate(bh))
-		buffer_error();
-	if (rw == WRITE && !buffer_uptodate(bh))
-		buffer_error();
-	if (rw == READ && buffer_dirty(bh))
-		buffer_error();
-
 	/* Only clear out a write error when rewriting */
 	if (test_set_buffer_req(bh) && rw == WRITE)
 		clear_buffer_write_io_error(bh);
@@ -2798,21 +2737,6 @@
 }
 
 /*
- * Sanity checks for try_to_free_buffers.
- */
-static void check_ttfb_buffer(struct page *page, struct buffer_head *bh)
-{
-	if (!buffer_uptodate(bh) && !buffer_req(bh)) {
-		if (PageUptodate(page) && page->mapping
-			&& buffer_mapped(bh)	/* discard_buffer */
-			&& S_ISBLK(page->mapping->host->i_mode))
-		{
-			buffer_error();
-		}
-	}
-}
-
-/*
  * try_to_free_buffers() checks if all the buffers on this particular page
  * are unused, and releases them if so.
  *
@@ -2847,7 +2771,6 @@
 
 	bh = head;
 	do {
-		check_ttfb_buffer(page, bh);
 		if (buffer_write_io_error(bh))
 			set_bit(AS_EIO, &page->mapping->flags);
 		if (buffer_busy(bh))
@@ -2856,9 +2779,6 @@
 			was_uptodate = 0;
 		bh = bh->b_this_page;
 	} while (bh != head);
-
-	if (!was_uptodate && PageUptodate(page) && !PageError(page))
-		buffer_error();
 
 	do {
 		struct buffer_head *next = bh->b_this_page;
===== fs/mpage.c 1.54 vs edited =====
--- 1.54/fs/mpage.c	Mon Apr 12 13:54:41 2004
+++ edited/fs/mpage.c	Wed Apr 14 04:33:06 2004
@@ -485,8 +485,7 @@
 			break;
 		block_in_file++;
 	}
-	if (page_block == 0)
-		buffer_error();
+	BUG_ON(page_block == 0);
 
 	first_unmapped = page_block;
 
===== fs/ext3/inode.c 1.90 vs edited =====
--- 1.90/fs/ext3/inode.c	Tue Jan 20 20:58:53 2004
+++ edited/fs/ext3/inode.c	Wed Apr 14 04:33:34 2004
@@ -1358,8 +1358,6 @@
 	}
 
 	if (!page_has_buffers(page)) {
-		if (!PageUptodate(page))
-			buffer_error();
 		create_empty_buffers(page, inode->i_sb->s_blocksize,
 				(1 << BH_Dirty)|(1 << BH_Uptodate));
 	}
===== fs/ntfs/aops.c 1.96 vs edited =====
--- 1.96/fs/ntfs/aops.c	Mon Apr 12 13:54:35 2004
+++ edited/fs/ntfs/aops.c	Wed Apr 14 04:33:30 2004
@@ -1340,8 +1340,6 @@
 			void *kaddr;
 
 			clear_buffer_new(bh);
-			if (buffer_uptodate(bh))
-				buffer_error();
 			kaddr = kmap_atomic(page, KM_USER0);
 			memset(kaddr + block_start, 0, bh->b_size);
 			kunmap_atomic(kaddr, KM_USER0);
===== fs/reiserfs/inode.c 1.97 vs edited =====
--- 1.97/fs/reiserfs/inode.c	Mon Apr 12 13:54:58 2004
+++ edited/fs/reiserfs/inode.c	Wed Apr 14 04:33:23 2004
@@ -1925,7 +1925,6 @@
     th.t_trans_id = 0;
 
     if (!buffer_uptodate(bh_result)) {
-        buffer_error();
 	return -EIO;
     }
 
@@ -2057,8 +2056,6 @@
      * in the BH_Uptodate is just a sanity check.
      */
     if (!page_has_buffers(page)) {
-	if (!PageUptodate(page))
-	    buffer_error();
 	create_empty_buffers(page, inode->i_sb->s_blocksize, 
 	                    (1 << BH_Dirty) | (1 << BH_Uptodate));
     }
@@ -2120,8 +2117,6 @@
 	    }
 	}
 	if (test_clear_buffer_dirty(bh)) {
-	    if (!buffer_uptodate(bh))
-		buffer_error();
 	    mark_buffer_async_write(bh);
 	} else {
 	    unlock_buffer(bh);
===== include/linux/buffer_head.h 1.47 vs edited =====
--- 1.47/include/linux/buffer_head.h	Wed Apr 14 03:18:09 2004
+++ edited/include/linux/buffer_head.h	Wed Apr 14 04:32:14 2004
@@ -62,13 +62,6 @@
 };
 
 /*
- * Debug
- */
-
-void __buffer_error(char *file, int line);
-#define buffer_error() __buffer_error(__FILE__, __LINE__)
-
-/*
  * macro tricks to expand the set_buffer_foo(), clear_buffer_foo()
  * and buffer_foo() functions.
  */

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>I would rather not kill the code in submit_bh() outright, just disable 
>> it for non-filesystem developers.
> 
> 
> submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called
> more often, possibly others.  Kill!

Jens seems to like the debugging checks, so here's an alterna-patch.

	Jeff



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 18145 bytes --]

===== arch/alpha/Kconfig 1.36 vs edited =====
--- 1.36/arch/alpha/Kconfig	Sat Mar 20 13:29:54 2004
+++ edited/arch/alpha/Kconfig	Wed Apr 14 04:58:08 2004
@@ -690,6 +690,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/arm/Kconfig 1.53 vs edited =====
--- 1.53/arch/arm/Kconfig	Thu Apr  8 15:41:09 2004
+++ edited/arch/arm/Kconfig	Wed Apr 14 04:58:08 2004
@@ -724,6 +724,13 @@
 	  you are concerned with the code size or don't want to see these
 	  messages.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 # These options are only for real kernel hackers who want to get their hands dirty. 
 config DEBUG_LL
 	bool "Kernel low-level debugging functions"
===== arch/arm26/Kconfig 1.11 vs edited =====
--- 1.11/arch/arm26/Kconfig	Mon Mar  1 10:52:18 2004
+++ edited/arch/arm26/Kconfig	Wed Apr 14 04:58:08 2004
@@ -316,6 +316,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 # These options are only for real kernel hackers who want to get their hands dirty. 
 config DEBUG_LL
 	bool "Kernel low-level debugging functions"
===== arch/i386/Kconfig 1.116 vs edited =====
--- 1.116/arch/i386/Kconfig	Mon Apr 12 13:54:45 2004
+++ edited/arch/i386/Kconfig	Wed Apr 14 04:58:08 2004
@@ -1286,6 +1286,13 @@
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.	
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
 	bool "Compile the kernel with frame pointers"
 	help
===== arch/ia64/Kconfig 1.69 vs edited =====
--- 1.69/arch/ia64/Kconfig	Mon Apr 12 21:50:46 2004
+++ edited/arch/ia64/Kconfig	Wed Apr 14 04:58:08 2004
@@ -503,6 +503,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config SYSVIPC_COMPAT
 	bool
 	depends on COMPAT && SYSVIPC
===== arch/m68k/Kconfig 1.31 vs edited =====
--- 1.31/arch/m68k/Kconfig	Thu Feb 26 06:25:58 2004
+++ edited/arch/m68k/Kconfig	Wed Apr 14 04:58:08 2004
@@ -688,6 +688,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/mips/Kconfig 1.24 vs edited =====
--- 1.24/arch/mips/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/mips/Kconfig	Wed Apr 14 04:58:08 2004
@@ -1253,6 +1253,13 @@
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config RTC_DS1742
 	bool "DS1742 BRAM/RTC support"
 	depends on TOSHIBA_JMR3927 || TOSHIBA_RBTX4927
===== arch/parisc/Kconfig 1.28 vs edited =====
--- 1.28/arch/parisc/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/parisc/Kconfig	Wed Apr 14 04:58:08 2004
@@ -222,6 +222,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/ppc/Kconfig 1.57 vs edited =====
--- 1.57/arch/ppc/Kconfig	Tue Mar 30 10:39:41 2004
+++ edited/arch/ppc/Kconfig	Wed Apr 14 04:58:08 2004
@@ -1209,6 +1209,13 @@
 	  debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config BOOTX_TEXT
 	bool "Support for early boot text console (BootX or OpenFirmware only)"
 	depends PPC_OF
===== arch/ppc64/Kconfig 1.52 vs edited =====
--- 1.52/arch/ppc64/Kconfig	Mon Apr 12 13:54:05 2004
+++ edited/arch/ppc64/Kconfig	Wed Apr 14 04:58:08 2004
@@ -395,6 +395,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/s390/Kconfig 1.25 vs edited =====
--- 1.25/arch/s390/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/s390/Kconfig	Wed Apr 14 04:58:08 2004
@@ -397,6 +397,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config DEBUG_SPINLOCK_SLEEP
 	bool "Sleep-inside-spinlock checking"
 	help
===== arch/sparc/Kconfig 1.28 vs edited =====
--- 1.28/arch/sparc/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/sparc/Kconfig	Wed Apr 14 04:58:08 2004
@@ -448,6 +448,13 @@
 	  of the BUG call as well as the EIP and oops trace.  This aids
 	  debugging but costs about 70-100K of memory.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 endmenu
 
 source "security/Kconfig"
===== arch/sparc64/Kconfig 1.50 vs edited =====
--- 1.50/arch/sparc64/Kconfig	Fri Mar 19 01:04:54 2004
+++ edited/arch/sparc64/Kconfig	Wed Apr 14 04:58:08 2004
@@ -679,6 +679,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config STACK_DEBUG
 	depends on DEBUG_KERNEL
 	bool "Stack Overflow Detection Support"
===== arch/um/Kconfig 1.14 vs edited =====
--- 1.14/arch/um/Kconfig	Mon Apr 12 13:53:57 2004
+++ edited/arch/um/Kconfig	Wed Apr 14 04:58:08 2004
@@ -233,6 +233,13 @@
         If you're truly short on disk space or don't expect to report any
         bugs back to the UML developers, say N, otherwise say Y.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
 	bool
 	default y if DEBUG_INFO
===== arch/v850/Kconfig 1.21 vs edited =====
--- 1.21/arch/v850/Kconfig	Mon Feb 16 19:42:32 2004
+++ edited/arch/v850/Kconfig	Wed Apr 14 04:58:08 2004
@@ -320,6 +320,13 @@
 	  Say Y here only if you plan to use gdb to debug the kernel.
 	  If you don't debug the kernel, you can say N.
 
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config MAGIC_SYSRQ
 	bool "Magic SysRq key"
 	depends on DEBUG_KERNEL
===== arch/x86_64/Kconfig 1.47 vs edited =====
--- 1.47/arch/x86_64/Kconfig	Mon Apr 12 13:53:56 2004
+++ edited/arch/x86_64/Kconfig	Wed Apr 14 04:58:08 2004
@@ -471,6 +471,13 @@
 	  Please note that this option requires new binutils.
 	  If you don't debug the kernel, you can say N.
 	  
+config DEBUG_BUFFERS
+	bool "Enable additional filesystem buffer_head checks"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, additional checks are performed that aid
+	  filesystem development.
+
 config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        help
===== fs/buffer.c 1.237 vs edited =====
--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
+++ edited/fs/buffer.c	Wed Apr 14 05:05:28 2004
@@ -55,6 +55,7 @@
  * Debug/devel support stuff
  */
 
+#ifdef CONFIG_DEBUG_BUFFERS
 void __buffer_error(char *file, int line)
 {
 	static int enough;
@@ -69,6 +70,7 @@
 	dump_stack();
 }
 EXPORT_SYMBOL(__buffer_error);
+#endif /* CONFIG_DEBUG_BUFFERS */
 
 inline void
 init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private)
@@ -105,10 +107,9 @@
 	 * waitqueue, which is used here. (Well.  Other locked buffers
 	 * against the page will pin it.  But complain anyway).
 	 */
-	if (atomic_read(&bh->b_count) == 0 &&
+	buffer_errchk  (atomic_read(&bh->b_count) == 0 &&
 			!PageLocked(bh->b_page) &&
-			!PageWriteback(bh->b_page))
-		buffer_error();
+			!PageWriteback(bh->b_page));
 
 	clear_buffer_locked(bh);
 	smp_mb__after_clear_bit();
@@ -125,9 +126,8 @@
 	wait_queue_head_t *wqh = bh_waitq_head(bh);
 	DEFINE_WAIT(wait);
 
-	if (atomic_read(&bh->b_count) == 0 &&
-			(!bh->b_page || !PageLocked(bh->b_page)))
-		buffer_error();
+	buffer_errchk(atomic_read(&bh->b_count) == 0 &&
+			(!bh->b_page || !PageLocked(bh->b_page)));
 
 	do {
 		prepare_to_wait(wqh, &wait, TASK_UNINTERRUPTIBLE);
@@ -146,8 +146,7 @@
 static void
 __set_page_buffers(struct page *page, struct buffer_head *head)
 {
-	if (page_has_buffers(page))
-		buffer_error();
+	buffer_errchk(page_has_buffers(page));
 	page_cache_get(page);
 	SetPagePrivate(page);
 	page->private = (unsigned long)head;
@@ -433,7 +432,7 @@
 		}
 		bh = bh->b_this_page;
 	} while (bh != head);
-	buffer_error();
+	BUG();
 	printk("block=%llu, b_blocknr=%llu\n",
 		(unsigned long long)block, (unsigned long long)bh->b_blocknr);
 	printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
@@ -847,10 +846,10 @@
 		struct buffer_head *bh = head;
 
 		do {
-			if (buffer_uptodate(bh))
+			if (likely(buffer_uptodate(bh)))
 				set_buffer_dirty(bh);
 			else
-				buffer_error();
+				BUG();
 			bh = bh->b_this_page;
 		} while (bh != head);
 	}
@@ -1151,7 +1150,7 @@
 	return page;
 
 failed:
-	buffer_error();
+	BUG();
 	unlock_page(page);
 	page_cache_release(page);
 	return NULL;
@@ -1247,8 +1246,7 @@
  */
 void fastcall mark_buffer_dirty(struct buffer_head *bh)
 {
-	if (!buffer_uptodate(bh))
-		buffer_error();
+	buffer_errchk(!buffer_uptodate(bh));
 	if (!buffer_dirty(bh) && !test_set_buffer_dirty(bh))
 		__set_page_dirty_nobuffers(bh->b_page);
 }
@@ -1267,7 +1265,7 @@
 		return;
 	}
 	printk(KERN_ERR "VFS: brelse: Trying to free free buffer\n");
-	buffer_error();		/* For the stack backtrace */
+	BUG();
 }
 
 /*
@@ -1294,8 +1292,7 @@
 		unlock_buffer(bh);
 		return bh;
 	} else {
-		if (buffer_dirty(bh))
-			buffer_error();
+		buffer_errchk(buffer_dirty(bh));
 		get_bh(bh);
 		bh->b_end_io = end_buffer_read_sync;
 		submit_bh(READ, bh);
@@ -1687,8 +1684,7 @@
 	old_bh = __find_get_block_slow(bdev, block, 0);
 	if (old_bh) {
 #if 0	/* This happens.  Later. */
-		if (buffer_dirty(old_bh))
-			buffer_error();
+		buffer_errchk(buffer_dirty(old_bh));
 #endif
 		clear_buffer_dirty(old_bh);
 		wait_on_buffer(old_bh);
@@ -1737,8 +1733,7 @@
 	last_block = (i_size_read(inode) - 1) >> inode->i_blkbits;
 
 	if (!page_has_buffers(page)) {
-		if (!PageUptodate(page))
-			buffer_error();
+		buffer_errchk(!PageUptodate(page));
 		create_empty_buffers(page, 1 << inode->i_blkbits,
 					(1 << BH_Dirty)|(1 << BH_Uptodate));
 	}
@@ -1768,8 +1763,7 @@
 			 * this page can be outside i_size when there is a
 			 * truncate in progress.
 			 *
-			 * if (buffer_mapped(bh))
-			 *	buffer_error();
+			 * buffer_errchk(buffer_mapped(bh));
 			 */
 			/*
 			 * The buffer was zeroed by block_write_full_page()
@@ -1777,8 +1771,7 @@
 			clear_buffer_dirty(bh);
 			set_buffer_uptodate(bh);
 		} else if (!buffer_mapped(bh) && buffer_dirty(bh)) {
-			if (buffer_new(bh))
-				buffer_error();
+			buffer_errchk(buffer_new(bh));
 			err = get_block(inode, block, bh, 1);
 			if (err)
 				goto recover;
@@ -1811,8 +1804,7 @@
 			continue;
 		}
 		if (test_clear_buffer_dirty(bh)) {
-			if (!buffer_uptodate(bh))
-				buffer_error();
+			buffer_errchk(!buffer_uptodate(bh));
 			mark_buffer_async_write(bh);
 		} else {
 			unlock_buffer(bh);
@@ -1942,8 +1934,7 @@
 				unmap_underlying_metadata(bh->b_bdev,
 							bh->b_blocknr);
 				if (PageUptodate(page)) {
-					if (!buffer_mapped(bh))
-						buffer_error();
+					buffer_errchk(!buffer_mapped(bh));
 					set_buffer_uptodate(bh);
 					continue;
 				}
@@ -2001,8 +1992,7 @@
 			void *kaddr;
 
 			clear_buffer_new(bh);
-			if (buffer_uptodate(bh))
-				buffer_error();
+			buffer_errchk(buffer_uptodate(bh));
 			kaddr = kmap_atomic(page, KM_USER0);
 			memset(kaddr+block_start, 0, bh->b_size);
 			kunmap_atomic(kaddr, KM_USER0);
@@ -2068,8 +2058,7 @@
 
 	if (!PageLocked(page))
 		PAGE_BUG(page);
-	if (PageUptodate(page))
-		buffer_error();
+	buffer_errchk(PageUptodate(page));
 	blocksize = 1 << inode->i_blkbits;
 	if (!page_has_buffers(page))
 		create_empty_buffers(page, blocksize, 0);
@@ -2692,12 +2681,9 @@
 	BUG_ON(!buffer_mapped(bh));
 	BUG_ON(!bh->b_end_io);
 
-	if ((rw == READ || rw == READA) && buffer_uptodate(bh))
-		buffer_error();
-	if (rw == WRITE && !buffer_uptodate(bh))
-		buffer_error();
-	if (rw == READ && buffer_dirty(bh))
-		buffer_error();
+	buffer_errchk((rw == READ || rw == READA) && buffer_uptodate(bh));
+	buffer_errchk(rw == WRITE && !buffer_uptodate(bh));
+	buffer_errchk(rw == READ && buffer_dirty(bh));
 
 	/* Only clear out a write error when rewriting */
 	if (test_set_buffer_req(bh) && rw == WRITE)
@@ -2807,7 +2793,7 @@
 			&& buffer_mapped(bh)	/* discard_buffer */
 			&& S_ISBLK(page->mapping->host->i_mode))
 		{
-			buffer_error();
+			BUG();
 		}
 	}
 }
@@ -2857,8 +2843,7 @@
 		bh = bh->b_this_page;
 	} while (bh != head);
 
-	if (!was_uptodate && PageUptodate(page) && !PageError(page))
-		buffer_error();
+	buffer_errchk(!was_uptodate && PageUptodate(page) && !PageError(page));
 
 	do {
 		struct buffer_head *next = bh->b_this_page;
===== fs/mpage.c 1.54 vs edited =====
--- 1.54/fs/mpage.c	Mon Apr 12 13:54:41 2004
+++ edited/fs/mpage.c	Wed Apr 14 05:06:40 2004
@@ -485,8 +485,7 @@
 			break;
 		block_in_file++;
 	}
-	if (page_block == 0)
-		buffer_error();
+	buffer_errchk(page_block == 0);
 
 	first_unmapped = page_block;
 
===== fs/ext3/inode.c 1.90 vs edited =====
--- 1.90/fs/ext3/inode.c	Tue Jan 20 20:58:53 2004
+++ edited/fs/ext3/inode.c	Wed Apr 14 05:06:48 2004
@@ -1358,8 +1358,7 @@
 	}
 
 	if (!page_has_buffers(page)) {
-		if (!PageUptodate(page))
-			buffer_error();
+		buffer_errchk(!PageUptodate(page));
 		create_empty_buffers(page, inode->i_sb->s_blocksize,
 				(1 << BH_Dirty)|(1 << BH_Uptodate));
 	}
===== fs/ntfs/aops.c 1.96 vs edited =====
--- 1.96/fs/ntfs/aops.c	Mon Apr 12 13:54:35 2004
+++ edited/fs/ntfs/aops.c	Wed Apr 14 05:06:55 2004
@@ -1340,8 +1340,7 @@
 			void *kaddr;
 
 			clear_buffer_new(bh);
-			if (buffer_uptodate(bh))
-				buffer_error();
+			buffer_errchk(buffer_uptodate(bh));
 			kaddr = kmap_atomic(page, KM_USER0);
 			memset(kaddr + block_start, 0, bh->b_size);
 			kunmap_atomic(kaddr, KM_USER0);
===== fs/reiserfs/inode.c 1.97 vs edited =====
--- 1.97/fs/reiserfs/inode.c	Mon Apr 12 13:54:58 2004
+++ edited/fs/reiserfs/inode.c	Wed Apr 14 05:07:16 2004
@@ -1924,10 +1924,8 @@
     /* catch places below that try to log something without starting a trans */
     th.t_trans_id = 0;
 
-    if (!buffer_uptodate(bh_result)) {
-        buffer_error();
+    if (!buffer_uptodate(bh_result))
 	return -EIO;
-    }
 
     kmap(bh_result->b_page) ;
 start_over:
@@ -2057,8 +2055,7 @@
      * in the BH_Uptodate is just a sanity check.
      */
     if (!page_has_buffers(page)) {
-	if (!PageUptodate(page))
-	    buffer_error();
+	buffer_errchk(!PageUptodate(page));
 	create_empty_buffers(page, inode->i_sb->s_blocksize, 
 	                    (1 << BH_Dirty) | (1 << BH_Uptodate));
     }
@@ -2120,8 +2117,7 @@
 	    }
 	}
 	if (test_clear_buffer_dirty(bh)) {
-	    if (!buffer_uptodate(bh))
-		buffer_error();
+	    buffer_errchk(!buffer_uptodate(bh));
 	    mark_buffer_async_write(bh);
 	} else {
 	    unlock_buffer(bh);
===== include/linux/buffer_head.h 1.47 vs edited =====
--- 1.47/include/linux/buffer_head.h	Wed Apr 14 03:18:09 2004
+++ edited/include/linux/buffer_head.h	Wed Apr 14 05:08:07 2004
@@ -7,6 +7,7 @@
 #ifndef _LINUX_BUFFER_HEAD_H
 #define _LINUX_BUFFER_HEAD_H
 
+#include <linux/config.h>
 #include <linux/types.h>
 #include <linux/fs.h>
 #include <linux/linkage.h>
@@ -65,8 +66,16 @@
  * Debug
  */
 
+#ifdef CONFIG_DEBUG_BUFFERS
 void __buffer_error(char *file, int line);
-#define buffer_error() __buffer_error(__FILE__, __LINE__)
+#define buffer_error(condition)					\
+	do {							\
+		if (unlikely(condition))			\
+			__buffer_error(__FILE__, __LINE__);	\
+	} while (0)
+#else
+#define buffer_error(condition)  do {} while (0)
+#endif
 
 /*
  * macro tricks to expand the set_buffer_foo(), clear_buffer_foo()

Re: [PATCH] conditionalize some boring buffer_head checks

[Matt Mackall]

On Wed, Apr 14, 2004 at 05:10:17AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> >>I would rather not kill the code in submit_bh() outright, just disable 
> >>it for non-filesystem developers.
> >
> >
> >submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called
> >more often, possibly others.  Kill!
> 
> Jens seems to like the debugging checks, so here's an alterna-patch.
> 
> 	Jeff
> 
> 

> ===== arch/alpha/Kconfig 1.36 vs edited =====
> +++ edited/arch/alpha/Kconfig	Wed Apr 14 04:58:08 2004
> @@ -690,6 +690,13 @@
>  	  Say Y here only if you plan to use gdb to debug the kernel.
>  	  If you don't debug the kernel, you can say N.
>  
> +config DEBUG_BUFFERS
> +	bool "Enable additional filesystem buffer_head checks"
> +	depends on DEBUG_KERNEL
> +	help
> +	  If you say Y here, additional checks are performed that aid
> +	  filesystem development.
> +
>  endmenu

Sticking this in arch/*/Kconfig seems silly (as does much of the
duplication in said files). Can we stick this and other debug bits
under the kallsyms option in init/Kconfig instead? Or alternately move
debugging bits into their own file that gets included as appropriate.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH] conditionalize some boring buffer_head checks

[Randy.Dunlap]

On Wed, 14 Apr 2004 16:25:39 -0500 Matt Mackall wrote:

| On Wed, Apr 14, 2004 at 05:10:17AM -0400, Jeff Garzik wrote:
| > Andrew Morton wrote:
| > >Jeff Garzik <jgarzik@pobox.com> wrote:
| > >
| > >>I would rather not kill the code in submit_bh() outright, just disable 
| > >>it for non-filesystem developers.
| > >
| > >
| > >submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called
| > >more often, possibly others.  Kill!
| > 
| > Jens seems to like the debugging checks, so here's an alterna-patch.
| > 
| > 	Jeff
| > 
| > 
| 
| > ===== arch/alpha/Kconfig 1.36 vs edited =====
| > +++ edited/arch/alpha/Kconfig	Wed Apr 14 04:58:08 2004
| > @@ -690,6 +690,13 @@
| >  	  Say Y here only if you plan to use gdb to debug the kernel.
| >  	  If you don't debug the kernel, you can say N.
| >  
| > +config DEBUG_BUFFERS
| > +	bool "Enable additional filesystem buffer_head checks"
| > +	depends on DEBUG_KERNEL
| > +	help
| > +	  If you say Y here, additional checks are performed that aid
| > +	  filesystem development.
| > +
| >  endmenu
| 
| Sticking this in arch/*/Kconfig seems silly (as does much of the
| duplication in said files). Can we stick this and other debug bits
| under the kallsyms option in init/Kconfig instead? Or alternately move
| debugging bits into their own file that gets included as appropriate.

Yes, I'll jump onto that if noone else does it.
Matt, are you making a patch for this?

--
~Randy
"We have met the enemy and he is us."  -- Pogo (by Walt Kelly)
(Again.  Sometimes I think ln -s /usr/src/linux/.config .signature)

Re: [PATCH] conditionalize some boring buffer_head checks

[Matt Mackall]

On Wed, Apr 14, 2004 at 02:27:54PM -0700, Randy.Dunlap wrote:
> On Wed, 14 Apr 2004 16:25:39 -0500 Matt Mackall wrote:
> 
> | On Wed, Apr 14, 2004 at 05:10:17AM -0400, Jeff Garzik wrote:
> | > Andrew Morton wrote:
> | > >Jeff Garzik <jgarzik@pobox.com> wrote:
> | > >
> | > >>I would rather not kill the code in submit_bh() outright, just disable 
> | > >>it for non-filesystem developers.
> | > >
> | > >
> | > >submit_bh() is a slowpath ;) The one in mark_buffer_dirty() will be called
> | > >more often, possibly others.  Kill!
> | > 
> | > Jens seems to like the debugging checks, so here's an alterna-patch.
> | > 
> | > 	Jeff
> | > 
> | > 
> | 
> | > ===== arch/alpha/Kconfig 1.36 vs edited =====
> | > +++ edited/arch/alpha/Kconfig	Wed Apr 14 04:58:08 2004
> | > @@ -690,6 +690,13 @@
> | >  	  Say Y here only if you plan to use gdb to debug the kernel.
> | >  	  If you don't debug the kernel, you can say N.
> | >  
> | > +config DEBUG_BUFFERS
> | > +	bool "Enable additional filesystem buffer_head checks"
> | > +	depends on DEBUG_KERNEL
> | > +	help
> | > +	  If you say Y here, additional checks are performed that aid
> | > +	  filesystem development.
> | > +
> | >  endmenu
> | 
> | Sticking this in arch/*/Kconfig seems silly (as does much of the
> | duplication in said files). Can we stick this and other debug bits
> | under the kallsyms option in init/Kconfig instead? Or alternately move
> | debugging bits into their own file that gets included as appropriate.
> 
> Yes, I'll jump onto that if noone else does it.
> Matt, are you making a patch for this?

It's all yours.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

On Wed, Apr 14, 2004 at 04:25:39PM -0500, Matt Mackall wrote:
> Sticking this in arch/*/Kconfig seems silly (as does much of the
> duplication in said files). Can we stick this and other debug bits
> under the kallsyms option in init/Kconfig instead? Or alternately move
> debugging bits into their own file that gets included as appropriate.

I would rather have an arch/generic/Kconfig.debug file that gets
included.  init/Kconfig may be generic, but its name hardly implies its
purpose as used.

There are clearly two classes of debug options, one arch-specific, and
one not.

	Jeff

Re: [PATCH] conditionalize some boring buffer_head checks

[Matt Mackall]

On Wed, Apr 14, 2004 at 05:33:36PM -0400, Jeff Garzik wrote:
> On Wed, Apr 14, 2004 at 04:25:39PM -0500, Matt Mackall wrote:
> > Sticking this in arch/*/Kconfig seems silly (as does much of the
> > duplication in said files). Can we stick this and other debug bits
> > under the kallsyms option in init/Kconfig instead? Or alternately move
> > debugging bits into their own file that gets included as appropriate.
> 
> I would rather have an arch/generic/Kconfig.debug file that gets
> included.  init/Kconfig may be generic, but its name hardly implies its
> purpose as used.

Yes, and it's rather a dumping ground too.

> There are clearly two classes of debug options, one arch-specific, and
> one not.

There is a third class of options that aren't intrinsically
arch-specific, but are currently implemented on only a subset of
architectures (eg kgdb), that I would argue properly belong in the
generic debug section.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH] conditionalize some boring buffer_head checks

[Zwane Mwaikambo]

On Wed, 14 Apr 2004, Jeff Garzik wrote:

> On Wed, Apr 14, 2004 at 04:25:39PM -0500, Matt Mackall wrote:
> > Sticking this in arch/*/Kconfig seems silly (as does much of the
> > duplication in said files). Can we stick this and other debug bits
> > under the kallsyms option in init/Kconfig instead? Or alternately move
> > debugging bits into their own file that gets included as appropriate.
>
> I would rather have an arch/generic/Kconfig.debug file that gets
> included.  init/Kconfig may be generic, but its name hardly implies its
> purpose as used.
>
> There are clearly two classes of debug options, one arch-specific, and
> one not.

This sounds like lib/Kconfig

PATCH] Kconfig.debug family

[Randy.Dunlap]

On Wed, 14 Apr 2004 16:25:39 -0500 Matt Mackall wrote:

| Sticking this in arch/*/Kconfig seems silly (as does much of the
| duplication in said files). Can we stick this and other debug bits
| under the kallsyms option in init/Kconfig instead? Or alternately move
| debugging bits into their own file that gets included as appropriate.


This patch:
- creates lib/Kconfig.debug for generic kernel debug options
- creates arch/*/Kconfig.debug for arch-specific debug options
- moves KALLSYMS to the generic kernel debug options list


This is a first cut for review/comments.  I will double-check
the generic options list to see how it needs to be corrected...

Applies to 2.6.6-rc1.
All arches have been tested by using 'make ARCH=foo {menu|x}config'.
However, ARCH=cris fails due to a missing file:
source "arch/cris/drivers/Kconfig".

--
~Randy


 arch/alpha/Kconfig.debug     |   54 ++++++++++++++
 arch/arm/Kconfig             |  159 -------------------------------------------
 arch/arm/Kconfig.debug       |  113 ++++++++++++++++++++++++++++++
 arch/arm26/Kconfig.debug     |   58 +++++++++++++++
 arch/cris/Kconfig.debug      |   15 ++++
 arch/h8300/Kconfig           |   71 -------------------
 arch/h8300/Kconfig.debug     |   67 ++++++++++++++++++
 arch/i386/Kconfig            |  124 ---------------------------------
 arch/i386/Kconfig.debug      |   15 ++++
 arch/ia64/Kconfig            |  113 ------------------------------
 arch/ia64/Kconfig.debug      |   63 +++++++++++++++++
 arch/m68k/Kconfig.debug      |    9 ++
 arch/m68knommu/Kconfig       |   54 --------------
 arch/m68knommu/Kconfig.debug |   42 +++++++++++
 arch/mips/Kconfig.debug      |   67 ++++++++++++++++++
 arch/parisc/Kconfig.debug    |    5 +
 arch/ppc/Kconfig.debug       |   72 +++++++++++++++++++
 arch/ppc64/Kconfig           |   79 ---------------------
 arch/ppc64/Kconfig.debug     |   27 +++++++
 arch/s390/Kconfig.debug      |    5 +
 arch/sh/Kconfig.debug        |  111 ++++++++++++++++++++++++++++++
 arch/sparc/Kconfig.debug     |   13 +++
 arch/sparc64/Kconfig.debug   |   38 ++++++++++
 arch/um/Kconfig              |   59 ---------------
 arch/um/Kconfig.debug        |   35 +++++++++
 arch/v850/Kconfig.debug      |   10 ++
 arch/x86_64/Kconfig          |  100 ---------------------------
 arch/x86_64/Kconfig.debug    |   47 ++++++++++++
 init/Kconfig                 |    8 --
 lib/Kconfig.debug            |  151 ++++++++++++++++++++++++++++++++++++++++
 30 files changed, 1033 insertions(+), 751 deletions(-)


diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/alpha/Kconfig.debug linux-266-rc1-kdebug/arch/alpha/Kconfig.debug
--- linux-266-rc1-pv/arch/alpha/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/alpha/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,54 @@
+
+menu "Alpha kernel hacking"
+
+config ALPHA_LEGACY_START_ADDRESS
+	bool "Legacy kernel start address"
+	depends on ALPHA_GENERIC
+	default n
+	---help---
+	  The 2.4 kernel changed the kernel start address from 0x310000
+	  to 0x810000 to make room for the Wildfire's larger SRM console.
+	  Recent consoles on Titan and Marvel machines also require the
+	  extra room.
+
+	  If you're using aboot 0.7 or later, the bootloader will examine the
+	  ELF headers to determine where to transfer control. Unfortunately,
+	  most older bootloaders -- APB or MILO -- hardcoded the kernel start
+	  address rather than examining the ELF headers, and the result is a
+	  hard lockup.
+
+	  Say Y if you have a broken bootloader.  Say N if you do not, or if
+	  you wish to run on Wildfire, Titan, or Marvel.
+
+config ALPHA_LEGACY_START_ADDRESS
+	bool
+	depends on !ALPHA_GENERIC && !ALPHA_TITAN && !ALPHA_MARVEL && !ALPHA_WILDFIRE
+	default y
+
+config MATHEMU
+	tristate "Kernel FP software completion" if DEBUG_KERNEL
+	default y if !DEBUG_KERNEL
+	help
+	  This option is required for IEEE compliant floating point arithmetic
+	  on the Alpha. The only time you would ever not say Y is to say M in
+	  order to debug the code. Say Y unless you know what you are doing.
+
+config DEBUG_RWLOCK
+	bool "Read-write spinlock debugging"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here then read-write lock processing will count how many
+	  times it has tried to get the lock and issue an error message after
+	  too many attempts.  If you suspect a rwlock problem or a kernel
+	  hacker asks for this option then say Y.  Otherwise say N.
+
+config DEBUG_SEMAPHORE
+	bool "Semaphore debugging"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here then semaphore processing will issue lots of
+	  verbose debugging messages.  If you suspect a semaphore problem or a
+	  kernel hacker asks for this option then say Y.  Otherwise say N.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/arm/Kconfig linux-266-rc1-kdebug/arch/arm/Kconfig
--- linux-266-rc1-pv/arch/arm/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/arm/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -621,164 +621,9 @@ source "drivers/misc/Kconfig"
 
 source "drivers/usb/Kconfig"
 
-
 menu "Kernel hacking"
-
-# RMK wants arm kernels compiled with frame pointers so hardwire this to y.
-# If you know what you are doing and are willing to live without stack
-# traces, you can get a slightly smaller kernel by setting this option to
-# n, but then RMK will have to kill you ;).
-config FRAME_POINTER
-	bool
-	default y
-	help
-	  If you say N here, the resulting kernel will be slightly smaller and
-	  faster. However, when a problem occurs with the kernel, the
-	  information that is reported is severely limited. Most people
-	  should say Y here.
-
-config DEBUG_USER
-	bool "Verbose user fault messages"
-	help
-	  When a user program crashes due to an exception, the kernel can
-	  print a brief message explaining what the problem was. This is
-	  sometimes helpful for debugging but serves no purpose on a
-	  production system. Most people should say N here.
-
-	  In addition, you need to pass user_debug=N on the kernel command
-	  line to enable this feature.  N consists of the sum of:
-
-	      1 - undefined instruction events
-	      2 - system calls
-	      4 - invalid data aborts
-	      8 - SIGSEGV faults
-	     16 - SIGBUS faults
-
-config DEBUG_INFO
-	bool "Include GDB debugging information in kernel binary"
-	help
-	  Say Y here to include source-level debugging information in the
-	  `vmlinux' binary image. This is handy if you want to use gdb or
-	  addr2line to debug the kernel. It has no impact on the in-memory
-	  footprint of the running kernel but it can increase the amount of
-	  time and disk space needed for compilation of the kernel. If in
-	  doubt say N.
-
-config DEBUG_KERNEL
-	bool "Kernel debugging"
-	help
-	  Say Y here if you are developing drivers or trying to debug and
-	  identify kernel problems.
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to have the kernel do limited verification on memory
-	  allocation as well as poisoning memory on free to catch use of freed
-	  memory.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	depends on DEBUG_KERNEL
-	help
-	  If you say Y here, you will have some control over the system even
-	  if the system crashes for example during kernel debugging (e.g., you
-	  will be able to flush the buffer cache to disk, reboot the system
-	  immediately or dump some status information). This is accomplished
-	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
-	  also works on a serial console (on PC hardware at least), if you
-	  send a BREAK and then within 5 seconds a command keypress. The
-	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
-	  unless you really know what this hack does.
-
-config DEBUG_SPINLOCK
-	bool "Spinlock debugging"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here and build SMP to catch missing spinlock initialization
-	  and certain other kinds of spinlock errors commonly made.  This is
-	  best used in conjunction with the NMI watchdog so that spinlock
-	  deadlocks are also debuggable.
-
-config DEBUG_WAITQ
-	bool "Wait queue debugging"
-	depends on DEBUG_KERNEL
-
-config DEBUG_BUGVERBOSE
-	bool "Verbose BUG() reporting (adds 70K)"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to make BUG() panics output the file name and line number
-	  of the BUG call as well as the EIP and oops trace.  This aids
-	  debugging but costs about 70-100K of memory.
-
-config DEBUG_ERRORS
-	bool "Verbose kernel error messages"
-	depends on DEBUG_KERNEL
-	help
-	  This option controls verbose debugging information which can be
-	  printed when the kernel detects an internal error. This debugging
-	  information is useful to kernel hackers when tracking down problems,
-	  but mostly meaningless to other people. It's safe to say Y unless
-	  you are concerned with the code size or don't want to see these
-	  messages.
-
-# These options are only for real kernel hackers who want to get their hands dirty. 
-config DEBUG_LL
-	bool "Kernel low-level debugging functions"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to include definitions of printascii, printchar, printhex
-	  in the kernel.  This is helpful if you are debugging code that
-	  executes before the console is initialized.
-
-config DEBUG_ICEDCC
-	bool "Kernel low-level debugging via EmbeddedICE DCC channel"
-	depends on DEBUG_LL
-	help
-	  Say Y here if you want the debug print routines to direct their
-	  output to the EmbeddedICE macrocell's DCC channel using
-	  co-processor 14. This is known to work on the ARM9 style ICE
-	  channel.
-
-	  It does include a timeout to ensure that the system does not
-	  totally freeze when there is nothing connected to read.
-
-config DEBUG_DC21285_PORT
-	bool "Kernel low-level debugging messages via footbridge serial port"
-	depends on DEBUG_LL && FOOTBRIDGE
-	help
-	  Say Y here if you want the debug print routines to direct their
-	  output to the serial port in the DC21285 (Footbridge). Saying N
-	  will cause the debug messages to appear on the first 16550
-	  serial port.
-
-config DEBUG_CLPS711X_UART2
-	bool "Kernel low-level debugging messages via UART2"
-	depends on DEBUG_LL && ARCH_CLPS711X
-	help
-	  Say Y here if you want the debug print routines to direct their
-	  output to the second serial port on these devices.  Saying N will
-	  cause the debug messages to appear on the first serial port.
-
-config DEBUG_S3C2410_PORT
-	depends on DEBUG_LL && ARCH_S3C2410
-	bool "Kernel low-level debugging messages via S3C2410 UART"
-	help
-	  Say Y here if you want debug print routines to go to one of the
-	  S3C2410 internal UARTs. The chosen UART must have been configured
-	  before it is used.
-
-config DEBUG_S3C2410_UART
-	int
-	depends on DEBUG_LL && ARCH_S3C2410
-	default "0"
-	help
-	  Choice for UART for kernel low-level using S3C2410 UARTS,
-	  should be between zero and two. The port must have been
-	  initalised by the boot-loader before use.
-
+source "lib/Kconfig.debug"
+source "arch/arm/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/arm/Kconfig.debug linux-266-rc1-kdebug/arch/arm/Kconfig.debug
--- linux-266-rc1-pv/arch/arm/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/arm/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,113 @@
+
+menu "ARM kernel hacking"
+
+# RMK wants arm kernels compiled with frame pointers so hardwire this to y.
+# If you know what you are doing and are willing to live without stack
+# traces, you can get a slightly smaller kernel by setting this option to
+# n, but then RMK will have to kill you ;).
+config FRAME_POINTER
+	bool
+	default y
+	help
+	  If you say N here, the resulting kernel will be slightly smaller and
+	  faster. However, when a problem occurs with the kernel, the
+	  information that is reported is severely limited. Most people
+	  should say Y here.
+
+config DEBUG_USER
+	bool "Verbose user fault messages"
+	help
+	  When a user program crashes due to an exception, the kernel can
+	  print a brief message explaining what the problem was. This is
+	  sometimes helpful for debugging but serves no purpose on a
+	  production system. Most people should say N here.
+
+	  In addition, you need to pass user_debug=N on the kernel command
+	  line to enable this feature.  N consists of the sum of:
+
+	      1 - undefined instruction events
+	      2 - system calls
+	      4 - invalid data aborts
+	      8 - SIGSEGV faults
+	     16 - SIGBUS faults
+
+config DEBUG_WAITQ
+	bool "Wait queue debugging"
+	depends on DEBUG_KERNEL
+
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting (adds 70K)"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to make BUG() panics output the file name and line number
+	  of the BUG call as well as the EIP and oops trace.  This aids
+	  debugging but costs about 70-100K of memory.
+
+config DEBUG_ERRORS
+	bool "Verbose kernel error messages"
+	depends on DEBUG_KERNEL
+	help
+	  This option controls verbose debugging information which can be
+	  printed when the kernel detects an internal error. This debugging
+	  information is useful to kernel hackers when tracking down problems,
+	  but mostly meaningless to other people. It's safe to say Y unless
+	  you are concerned with the code size or don't want to see these
+	  messages.
+
+# These options are only for real kernel hackers who want to get their hands dirty. 
+config DEBUG_LL
+	bool "Kernel low-level debugging functions"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to include definitions of printascii, printchar, printhex
+	  in the kernel.  This is helpful if you are debugging code that
+	  executes before the console is initialized.
+
+config DEBUG_ICEDCC
+	bool "Kernel low-level debugging via EmbeddedICE DCC channel"
+	depends on DEBUG_LL
+	help
+	  Say Y here if you want the debug print routines to direct their
+	  output to the EmbeddedICE macrocell's DCC channel using
+	  co-processor 14. This is known to work on the ARM9 style ICE
+	  channel.
+
+	  It does include a timeout to ensure that the system does not
+	  totally freeze when there is nothing connected to read.
+
+config DEBUG_DC21285_PORT
+	bool "Kernel low-level debugging messages via footbridge serial port"
+	depends on DEBUG_LL && FOOTBRIDGE
+	help
+	  Say Y here if you want the debug print routines to direct their
+	  output to the serial port in the DC21285 (Footbridge). Saying N
+	  will cause the debug messages to appear on the first 16550
+	  serial port.
+
+config DEBUG_CLPS711X_UART2
+	bool "Kernel low-level debugging messages via UART2"
+	depends on DEBUG_LL && ARCH_CLPS711X
+	help
+	  Say Y here if you want the debug print routines to direct their
+	  output to the second serial port on these devices.  Saying N will
+	  cause the debug messages to appear on the first serial port.
+
+config DEBUG_S3C2410_PORT
+	depends on DEBUG_LL && ARCH_S3C2410
+	bool "Kernel low-level debugging messages via S3C2410 UART"
+	help
+	  Say Y here if you want debug print routines to go to one of the
+	  S3C2410 internal UARTs. The chosen UART must have been configured
+	  before it is used.
+
+config DEBUG_S3C2410_UART
+	int
+	depends on DEBUG_LL && ARCH_S3C2410
+	default "0"
+	help
+	  Choice for UART for kernel low-level using S3C2410 UARTS,
+	  should be between zero and two. The port must have been
+	  initalised by the boot-loader before use.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/arm26/Kconfig.debug linux-266-rc1-kdebug/arch/arm26/Kconfig.debug
--- linux-266-rc1-pv/arch/arm26/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/arm26/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,58 @@
+
+menu "ARM26 kernel hacking"
+
+# RMK wants arm kernels compiled with frame pointers so hardwire this to y.
+# If you know what you are doing and are willing to live without stack
+# traces, you can get a slightly smaller kernel by setting this option to
+# n, but then RMK will have to kill you ;).
+config FRAME_POINTER
+	bool
+	default y
+	help
+	  If you say N here, the resulting kernel will be slightly smaller and
+	  faster. However, when a problem occurs with the kernel, the
+	  information that is reported is severely limited. Most people
+	  should say Y here.
+
+config DEBUG_USER
+	bool "Verbose user fault messages"
+	help
+	  When a user program crashes due to an exception, the kernel can
+	  print a brief message explaining what the problem was. This is
+	  sometimes helpful for debugging but serves no purpose on a
+	  production system. Most people should say N here.
+
+config DEBUG_WAITQ
+	bool "Wait queue debugging"
+	depends on DEBUG_KERNEL
+
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting (adds 70K)"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to make BUG() panics output the file name and line number
+	  of the BUG call as well as the EIP and oops trace.  This aids
+	  debugging but costs about 70-100K of memory.
+
+config DEBUG_ERRORS
+	bool "Verbose kernel error messages"
+	depends on DEBUG_KERNEL
+	help
+	  This option controls verbose debugging information which can be
+	  printed when the kernel detects an internal error. This debugging
+	  information is useful to kernel hackers when tracking down problems,
+	  but mostly meaningless to other people. It's safe to say Y unless
+	  you are concerned with the code size or don't want to see these
+	  messages.
+
+# These options are only for real kernel hackers who want to get their hands dirty. 
+config DEBUG_LL
+	bool "Kernel low-level debugging functions"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to include definitions of printascii, printchar, printhex
+	  in the kernel.  This is helpful if you are debugging code that
+	  executes before the console is initialized.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/cris/Kconfig.debug linux-266-rc1-kdebug/arch/cris/Kconfig.debug
--- linux-266-rc1-pv/arch/cris/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/cris/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,15 @@
+
+menu "CRIS kernel hacking"
+
+#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
+
+config PROFILE
+	bool "Kernel profiling support"
+
+config PROFILE_SHIFT
+	int "Profile shift count"
+	depends on PROFILE
+	default "2"
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/h8300/Kconfig linux-266-rc1-kdebug/arch/h8300/Kconfig
--- linux-266-rc1-pv/arch/h8300/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/h8300/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -297,75 +297,8 @@ endmenu
 source "fs/Kconfig"
 
 menu "Kernel hacking"
-
-config FULLDEBUG
-	bool "Full Symbolic/Source Debugging support"
-	help
-	  Enable debugging symbols on kernel build.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	help
-	  Enables console device to interprent special characters as
-	  commands to dump state information.
-
-config HIGHPROFILE
-	bool "Use fast second timer for profiling"
-	help
-	  Use a fast secondary clock to produce profiling information.
-
-config NO_KERNEL_MSG
-	bool "Suppress Kernel BUG Messages"
-	help
-	  Do not output any debug BUG messages within the kernel.
-
-config GDB_MAGICPRINT
-	bool "Message Output for GDB MagicPrint service"
-	depends on (H8300H_SIM || H8S_SIM)
-	help
-	  kernel messages output useing MagicPrint service from GDB
-
-config SYSCALL_PRINT
-	bool "SystemCall trace print"
-	help
-	  outout history of systemcall
-
-config GDB_DEBUG
-   	bool "Use gdb stub"
-	depends on (!H8300H_SIM && !H8S_SIM)
-	help
-	  gdb stub exception support
-
-config CONFIG_SH_STANDARD_BIOS
-	bool "Use gdb protocol serial console"
-	depends on (!H8300H_SIM && H8S_SIM)
-	help
-	  serial console output using GDB protocol.
-	  Require eCos/RedBoot
-
-config DEFAULT_CMDLINE
-	bool "Use buildin commandline"
-	default n
-	help
-	  buildin kernel commandline enabled.
-
-config KERNEL_COMMAND
-	string "Buildin commmand string"
-	depends on DEFAULT_CMDLINE
-	help
-	  buildin kernel commandline strings.
-
-config BLKDEV_RESERVE
-	bool "BLKDEV Reserved Memory"
-	default n
-	help
-	  Reserved BLKDEV area.
-
-config CONFIG_BLKDEV_RESERVE_ADDRESS
-	hex 'start address'
-	depends on BLKDEV_RESERVE
-	help
-	  BLKDEV start address.
+source "lib/Kconfig.debug"
+source "arch/h8300/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/h8300/Kconfig.debug linux-266-rc1-kdebug/arch/h8300/Kconfig.debug
--- linux-266-rc1-pv/arch/h8300/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/h8300/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,67 @@
+
+menu "H8300 kernel hacking"
+
+config FULLDEBUG
+	bool "Full Symbolic/Source Debugging support"
+	help
+	  Enable debugging symbols on kernel build.
+
+config HIGHPROFILE
+	bool "Use fast second timer for profiling"
+	help
+	  Use a fast secondary clock to produce profiling information.
+
+config NO_KERNEL_MSG
+	bool "Suppress Kernel BUG Messages"
+	help
+	  Do not output any debug BUG messages within the kernel.
+
+config GDB_MAGICPRINT
+	bool "Message Output for GDB MagicPrint service"
+	depends on (H8300H_SIM || H8S_SIM)
+	help
+	  kernel messages output useing MagicPrint service from GDB
+
+config SYSCALL_PRINT
+	bool "SystemCall trace print"
+	help
+	  outout history of systemcall
+
+config GDB_DEBUG
+   	bool "Use gdb stub"
+	depends on (!H8300H_SIM && !H8S_SIM)
+	help
+	  gdb stub exception support
+
+config CONFIG_SH_STANDARD_BIOS
+	bool "Use gdb protocol serial console"
+	depends on (!H8300H_SIM && H8S_SIM)
+	help
+	  serial console output using GDB protocol.
+	  Require eCos/RedBoot
+
+config DEFAULT_CMDLINE
+	bool "Use buildin commandline"
+	default n
+	help
+	  buildin kernel commandline enabled.
+
+config KERNEL_COMMAND
+	string "Buildin commmand string"
+	depends on DEFAULT_CMDLINE
+	help
+	  buildin kernel commandline strings.
+
+config BLKDEV_RESERVE
+	bool "BLKDEV Reserved Memory"
+	default n
+	help
+	  Reserved BLKDEV area.
+
+config CONFIG_BLKDEV_RESERVE_ADDRESS
+	hex 'start address'
+	depends on BLKDEV_RESERVE
+	help
+	  BLKDEV start address.
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/i386/Kconfig linux-266-rc1-kdebug/arch/i386/Kconfig
--- linux-266-rc1-pv/arch/i386/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/i386/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -1190,129 +1190,9 @@ source "fs/Kconfig"
 
 source "arch/i386/oprofile/Kconfig"
 
-
 menu "Kernel hacking"
-
-config DEBUG_KERNEL
-	bool "Kernel debugging"
-	help
-	  Say Y here if you are developing drivers or trying to debug and
-	  identify kernel problems.
-
-config EARLY_PRINTK
-	bool "Early printk" if EMBEDDED
-	default y
-	help
-	  Write kernel log output directly into the VGA buffer or to a serial
-	  port.
-
-	  This is useful for kernel debugging when your machine crashes very
-	  early before the console code is initialized. For normal operation
-	  it is not recommended because it looks ugly and doesn't cooperate
-	  with klogd/syslogd or the X server. You should normally N here,
-	  unless you want to debug such a crash.
-
-config DEBUG_STACKOVERFLOW
-	bool "Check for stack overflows"
-	depends on DEBUG_KERNEL
-
-config DEBUG_STACK_USAGE
-	bool "Stack utilization instrumentation"
-	depends on DEBUG_KERNEL
-	help
-	  Enables the display of the minimum amount of free stack which each
-	  task has ever had available in the sysrq-T and sysrq-P debug output.
-
-	  This option will slow down process creation somewhat.
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to have the kernel do limited verification on memory
-	  allocation as well as poisoning memory on free to catch use of freed
-	  memory.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	depends on DEBUG_KERNEL
-	help
-	  If you say Y here, you will have some control over the system even
-	  if the system crashes for example during kernel debugging (e.g., you
-	  will be able to flush the buffer cache to disk, reboot the system
-	  immediately or dump some status information). This is accomplished
-	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
-	  also works on a serial console (on PC hardware at least), if you
-	  send a BREAK and then within 5 seconds a command keypress. The
-	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
-	  unless you really know what this hack does.
-
-config DEBUG_SPINLOCK
-	bool "Spinlock debugging"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here and build SMP to catch missing spinlock initialization
-	  and certain other kinds of spinlock errors commonly made.  This is
-	  best used in conjunction with the NMI watchdog so that spinlock
-	  deadlocks are also debuggable.
-
-config DEBUG_PAGEALLOC
-	bool "Page alloc debugging"
-	depends on DEBUG_KERNEL
-	help
-	  Unmap pages from the kernel linear mapping after free_pages().
-	  This results in a large slowdown, but helps to find certain types
-	  of memory corruptions.
-
-config DEBUG_HIGHMEM
-	bool "Highmem debugging"
-	depends on DEBUG_KERNEL && HIGHMEM
-	help
-	  This options enables addition error checking for high memory systems.
-	  Disable for production systems.
-
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	help
-          If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  If you don't debug the kernel, you can say N.
-	  
-config DEBUG_SPINLOCK_SLEEP
-	bool "Sleep-inside-spinlock checking"
-	help
-	  If you say Y here, various routines which may sleep will become very
-	  noisy if they are called with a spinlock held.	
-
-config FRAME_POINTER
-	bool "Compile the kernel with frame pointers"
-	help
-	  If you say Y here the resulting kernel image will be slightly larger
-	  and slower, but it will give very useful debugging information.
-	  If you don't debug the kernel, you can say N, but we may not be able
-	  to solve problems without frame pointers.
-
-config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
-	help
-	  If you say Y here the kernel will use a 4Kb stacksize for the
-	  kernel stack attached to each process/thread. This facilitates
-	  running more threads on a system and also reduces the pressure
-	  on the VM subsystem for higher order allocations. This option
-	  will also use IRQ stacks to compensate for the reduced stackspace.
-
-config X86_FIND_SMP_CONFIG
-	bool
-	depends on X86_LOCAL_APIC || X86_VOYAGER
-	default y
-
-config X86_MPPARSE
-	bool
-	depends on X86_LOCAL_APIC && !X86_VISWS
-	default y
-
+source "lib/Kconfig.debug"
+source "arch/i386/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/i386/Kconfig.debug linux-266-rc1-kdebug/arch/i386/Kconfig.debug
--- linux-266-rc1-pv/arch/i386/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/i386/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,15 @@
+
+menu "X86 kernel hacking"
+
+config X86_FIND_SMP_CONFIG
+	bool
+	depends on X86_LOCAL_APIC || X86_VOYAGER
+	default y
+
+config X86_MPPARSE
+	bool
+	depends on X86_LOCAL_APIC && !X86_VISWS
+	default y
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/ia64/Kconfig linux-266-rc1-kdebug/arch/ia64/Kconfig
--- linux-266-rc1-pv/arch/ia64/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/ia64/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -396,117 +396,8 @@ source "arch/ia64/hp/sim/Kconfig"
 source "arch/ia64/oprofile/Kconfig"
 
 menu "Kernel hacking"
-
-choice
-	prompt "Physical memory granularity"
-	default IA64_GRANULE_64MB
-
-config IA64_GRANULE_16MB
-	bool "16MB"
-	help
-	  IA-64 identity-mapped regions use a large page size called "granules".
-
-	  Select "16MB" for a small granule size.
-	  Select "64MB" for a large granule size.  This is the current default.
-
-config IA64_GRANULE_64MB
-	bool "64MB"
-	depends on !(IA64_GENERIC || IA64_HP_ZX1)
-
-endchoice
-
-config DEBUG_KERNEL
-	bool "Kernel debugging"
-	help
-	  Say Y here if you are developing drivers or trying to debug and
-	  identify kernel problems.
-
-config IA64_PRINT_HAZARDS
-	bool "Print possible IA-64 dependency violations to console"
-	depends on DEBUG_KERNEL
-	help
-	  Selecting this option prints more information for Illegal Dependency
-	  Faults, that is, for Read-after-Write (RAW), Write-after-Write (WAW),
-	  or Write-after-Read (WAR) violations.  This option is ignored if you
-	  are compiling for an Itanium A step processor
-	  (CONFIG_ITANIUM_ASTEP_SPECIFIC).  If you're unsure, select Y.
-
-config DISABLE_VHPT
-	bool "Disable VHPT"
-	depends on DEBUG_KERNEL
-	help
-	  The Virtual Hash Page Table (VHPT) enhances virtual address
-	  translation performance.  Normally you want the VHPT active but you
-	  can select this option to disable the VHPT for debugging.  If you're
-	  unsure, answer N.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	depends on DEBUG_KERNEL
-	help
-	  If you say Y here, you will have some control over the system even
-	  if the system crashes for example during kernel debugging (e.g., you
-	  will be able to flush the buffer cache to disk, reboot the system
-	  immediately or dump some status information). This is accomplished
-	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
-	  also works on a serial console (on PC hardware at least), if you
-	  send a BREAK and then within 5 seconds a command keypress. The
-	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
-	  unless you really know what this hack does.
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to have the kernel do limited verification on memory
-	  allocation as well as poisoning memory on free to catch use of freed
-	  memory.
-
-config DEBUG_SPINLOCK
-	bool "Spinlock debugging"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here and build SMP to catch missing spinlock initialization
-	  and certain other kinds of spinlock errors commonly made.  This is
-	  best used in conjunction with the NMI watchdog so that spinlock
-	  deadlocks are also debuggable.
-
-config DEBUG_SPINLOCK_SLEEP
-	  bool "Sleep-inside-spinlock checking"
-	  help
-	    If you say Y here, various routines which may sleep will become very
-	    noisy if they are called with a spinlock held.
-
-config IA64_DEBUG_CMPXCHG
-	bool "Turn on compare-and-exchange bug checking (slow!)"
-	depends on DEBUG_KERNEL
-	help
-	  Selecting this option turns on bug checking for the IA-64
-	  compare-and-exchange instructions.  This is slow!  Itaniums
-	  from step B3 or later don't have this problem. If you're unsure,
-	  select N.
-
-config IA64_DEBUG_IRQ
-	bool "Turn on irq debug checks (slow!)"
-	depends on DEBUG_KERNEL
-	help
-	  Selecting this option turns on bug checking for the IA-64 irq_save
-	  and restore instructions.  It's useful for tracking down spinlock
-	  problems, but slow!  If you're unsure, select N.
-
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	help
-          If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  If you don't debug the kernel, you can say N.
-
-config SYSVIPC_COMPAT
-	bool
-	depends on COMPAT && SYSVIPC
-	default y
+source "lib/Kconfig.debug"
+source "arch/ia64/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/ia64/Kconfig.debug linux-266-rc1-kdebug/arch/ia64/Kconfig.debug
--- linux-266-rc1-pv/arch/ia64/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/ia64/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,63 @@
+
+menu "IA64 kernel hacking"
+
+choice
+	prompt "Physical memory granularity"
+	default IA64_GRANULE_64MB
+
+config IA64_GRANULE_16MB
+	bool "16MB"
+	help
+	  IA-64 identity-mapped regions use a large page size called "granules".
+
+	  Select "16MB" for a small granule size.
+	  Select "64MB" for a large granule size.  This is the current default.
+
+config IA64_GRANULE_64MB
+	bool "64MB"
+	depends on !(IA64_GENERIC || IA64_HP_ZX1)
+
+endchoice
+
+config IA64_PRINT_HAZARDS
+	bool "Print possible IA-64 dependency violations to console"
+	depends on DEBUG_KERNEL
+	help
+	  Selecting this option prints more information for Illegal Dependency
+	  Faults, that is, for Read-after-Write (RAW), Write-after-Write (WAW),
+	  or Write-after-Read (WAR) violations.  This option is ignored if you
+	  are compiling for an Itanium A step processor
+	  (CONFIG_ITANIUM_ASTEP_SPECIFIC).  If you're unsure, select Y.
+
+config DISABLE_VHPT
+	bool "Disable VHPT"
+	depends on DEBUG_KERNEL
+	help
+	  The Virtual Hash Page Table (VHPT) enhances virtual address
+	  translation performance.  Normally you want the VHPT active but you
+	  can select this option to disable the VHPT for debugging.  If you're
+	  unsure, answer N.
+
+config IA64_DEBUG_CMPXCHG
+	bool "Turn on compare-and-exchange bug checking (slow!)"
+	depends on DEBUG_KERNEL
+	help
+	  Selecting this option turns on bug checking for the IA-64
+	  compare-and-exchange instructions.  This is slow!  Itaniums
+	  from step B3 or later don't have this problem. If you're unsure,
+	  select N.
+
+config IA64_DEBUG_IRQ
+	bool "Turn on irq debug checks (slow!)"
+	depends on DEBUG_KERNEL
+	help
+	  Selecting this option turns on bug checking for the IA-64 irq_save
+	  and restore instructions.  It's useful for tracking down spinlock
+	  problems, but slow!  If you're unsure, select N.
+
+config SYSVIPC_COMPAT
+	bool
+	depends on COMPAT && SYSVIPC
+	default y
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/m68k/Kconfig.debug linux-266-rc1-kdebug/arch/m68k/Kconfig.debug
--- linux-266-rc1-pv/arch/m68k/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/m68k/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,9 @@
+
+menu "M68K kernel hacking"
+
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting"
+	depends on DEBUG_KERNEL
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/m68knommu/Kconfig linux-266-rc1-kdebug/arch/m68knommu/Kconfig
--- linux-266-rc1-pv/arch/m68knommu/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/m68knommu/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -512,58 +512,8 @@ source "drivers/Kconfig"
 source "fs/Kconfig"
 
 menu "Kernel hacking"
-
-config FULLDEBUG
-	bool "Full Symbolic/Source Debugging support"
-	help
-	  Enable debuging symbols on kernel build.
-
-config FRAME_POINTER
-	bool "Compile the kernel with frame pointers"
-	help
-	  If you say Y here the resulting kernel image will be slightly larger
-	  and slower, but it will give very useful debugging information.
-	  If you don't debug the kernel, you can say N, but we may not be able
-	  to solve problems without frame pointers.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	help
-	  Enables console device to interpret special characters as
-	  commands to dump state information.
-
-config HIGHPROFILE
-	bool "Use fast second timer for profiling"
-	depends on COLDFIRE
-	help
-	  Use a fast secondary clock to produce profiling information.
-
-config BOOTPARAM
-	bool 'Compiled-in Kernel Boot Parameter'
-
-config BOOTPARAM_STRING 
-	string 'Kernel Boot Parameter'
-	default 'console=ttyS0,19200'
-	depends on BOOTPARAM
-
-config DUMPTOFLASH
-	bool "Panic/Dump to FLASH"
-	depends on COLDFIRE
-	help
-	  Dump any panic of trap output into a flash memory segment
-	  for later analysis.
-
-config NO_KERNEL_MSG
-	bool "Suppress Kernel BUG Messages"
-	help
-	  Do not output any debug BUG messages within the kernel.
-
-config BDM_DISABLE
-	bool "Disable BDM signals"
-	depends on (EXPERIMENTAL && COLDFIRE)
-	help
-	  Disable the ColdFire CPU's BDM signals.
-
+source "lib/Kconfig.debug"
+source "arch/m68knommu/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/m68knommu/Kconfig.debug linux-266-rc1-kdebug/arch/m68knommu/Kconfig.debug
--- linux-266-rc1-pv/arch/m68knommu/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/m68knommu/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,42 @@
+
+menu "M68K-nommu kernel hacking"
+
+config FULLDEBUG
+	bool "Full Symbolic/Source Debugging support"
+	help
+	  Enable debuging symbols on kernel build.
+
+config HIGHPROFILE
+	bool "Use fast second timer for profiling"
+	depends on COLDFIRE
+	help
+	  Use a fast secondary clock to produce profiling information.
+
+config BOOTPARAM
+	bool 'Compiled-in Kernel Boot Parameter'
+
+config BOOTPARAM_STRING 
+	string 'Kernel Boot Parameter'
+	default 'console=ttyS0,19200'
+	depends on BOOTPARAM
+
+config DUMPTOFLASH
+	bool "Panic/Dump to FLASH"
+	depends on COLDFIRE
+	help
+	  Dump any panic of trap output into a flash memory segment
+	  for later analysis.
+
+config NO_KERNEL_MSG
+	bool "Suppress Kernel BUG Messages"
+	help
+	  Do not output any debug BUG messages within the kernel.
+
+config BDM_DISABLE
+	bool "Disable BDM signals"
+	depends on (EXPERIMENTAL && COLDFIRE)
+	help
+	  Disable the ColdFire CPU's BDM signals.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/mips/Kconfig.debug linux-266-rc1-kdebug/arch/mips/Kconfig.debug
--- linux-266-rc1-pv/arch/mips/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/mips/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,67 @@
+
+menu "MIPS kernel hacking"
+
+config CROSSCOMPILE
+	bool "Are you using a crosscompiler"
+	help
+	  Say Y here if you are compiling the kernel on a different
+	  architecture than the one it is intended to run on.
+
+config CMDLINE
+	string "Default kernel command string"
+	default ""
+	help
+          On some platforms, there is currently no way for the boot loader to
+          pass arguments to the kernel. For these platforms, you can supply
+          some command-line options at build time by entering them here.  In
+          other cases you can specify kernel args so that you don't have
+	  to set them up in board prom initialization routines.
+
+config KGDB
+	bool "Remote GDB kernel debugging"
+	depends on DEBUG_KERNEL
+	select DEBUG_INFO
+	help
+	  If you say Y here, it will be possible to remotely debug the MIPS
+	  kernel using gdb. This enlarges your kernel image disk size by
+	  several megabytes and requires a machine with more than 16 MB,
+	  better 32 MB RAM to avoid excessive linking time. This is only
+	  useful for kernel hackers. If unsure, say N.
+
+config GDB_CONSOLE
+	bool "Console output to GDB"
+	depends on KGDB
+	help
+	  If you are using GDB for remote debugging over a serial port and
+	  would like kernel messages to be formatted into GDB $O packets so
+	  that GDB prints them as program output, say 'Y'.
+
+config SB1XXX_CORELIS
+	bool "Corelis Debugger"
+	depends on SIBYTE_SB1xxx_SOC && DEBUG_INFO
+	help
+	  Select compile flags that produce code that can be processed by the
+	  Corelis mksym utility and UDB Emulator.
+
+config RUNTIME_DEBUG
+	bool "Enable run-time debugging"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, some debugging macros will do run-time checking.
+	  If you say N here, those macros will mostly turn to no-ops.  See 
+	  include/asm-mips/debug.h for debuging macros.
+	  If unsure, say N.
+
+
+config MIPS_UNCACHED
+	bool "Run uncached"
+	depends on DEBUG_KERNEL && !SMP && !SGI_IP27
+	help
+	  If you say Y here there kernel will disable all CPU caches.  This will
+	  reduce the system's performance dramatically but can help finding
+	  otherwise hard to track bugs.  It can also useful if you're doing
+	  hardware debugging with a logic analyzer and need to see all traffic
+	  on the bus.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/parisc/Kconfig.debug linux-266-rc1-kdebug/arch/parisc/Kconfig.debug
--- linux-266-rc1-pv/arch/parisc/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/parisc/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,5 @@
+
+menu "PA-RISC kernel hacking"
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/ppc/Kconfig.debug linux-266-rc1-kdebug/arch/ppc/Kconfig.debug
--- linux-266-rc1-pv/arch/ppc/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/ppc/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,72 @@
+
+menu "PPC kernel hacking"
+
+config KGDB
+	bool "Include kgdb kernel debugger"
+	depends on DEBUG_KERNEL
+	select DEBUG_INFO
+	help
+	  Include in-kernel hooks for kgdb, the Linux kernel source level
+	  debugger.  See <http://kgdb.sourceforge.net/> for more information.
+	  Unless you are intending to debug the kernel, say N here.
+
+choice
+	prompt "Serial Port"
+	depends on KGDB
+	default KGDB_TTYS1
+
+config KGDB_TTYS0
+	bool "ttyS0"
+
+config KGDB_TTYS1
+	bool "ttyS1"
+
+config KGDB_TTYS2
+	bool "ttyS2"
+
+config KGDB_TTYS3
+	bool "ttyS3"
+
+endchoice
+
+config KGDB_CONSOLE
+	bool "Enable serial console thru kgdb port"
+	depends on KGDB && 8xx || 8260
+	help
+	  If you enable this, all serial console messages will be sent
+	  over the gdb stub.
+	  If unsure, say N.
+
+config XMON
+	bool "Include xmon kernel debugger"
+	depends on DEBUG_KERNEL
+	help
+	  Include in-kernel hooks for the xmon kernel monitor/debugger.
+	  Unless you are intending to debug the kernel, say N here.
+
+config BDI_SWITCH
+	bool "Include BDI-2000 user context switcher"
+	depends on DEBUG_KERNEL
+	help
+	  Include in-kernel support for the Abatron BDI2000 debugger.
+	  Unless you are intending to debug the kernel with one of these
+	  machines, say N here.
+
+config BOOTX_TEXT
+	bool "Support for early boot text console (BootX or OpenFirmware only)"
+	depends PPC_OF
+	help
+	  Say Y here to see progress messages from the boot firmware in text
+	  mode. Requires either BootX or Open Firmware.
+
+config SERIAL_TEXT_DEBUG
+	bool "Support for early boot texts over serial port"
+	depends on 4xx || GT64260 || LOPEC || PPLUS || PRPMC800 || PPC_GEN550
+
+config OCP
+	bool
+	depends on IBM_OCP
+	default y
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/ppc64/Kconfig linux-266-rc1-kdebug/arch/ppc64/Kconfig
--- linux-266-rc1-pv/arch/ppc64/Kconfig	2004-04-15 14:00:10.000000000 -0700
+++ linux-266-rc1-kdebug/arch/ppc64/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -28,10 +28,6 @@ config HAVE_DEC_LOCK
 	bool
 	default y
 
-config EARLY_PRINTK
-	bool
-	default y
-
 config COMPAT
 	bool
 	default y
@@ -322,79 +318,8 @@ config VIOPATH
 source "arch/ppc64/oprofile/Kconfig"
 
 menu "Kernel hacking"
-
-config DEBUG_KERNEL
-	bool "Kernel debugging"
-	help
-	  Say Y here if you are developing drivers or trying to debug and
-	  identify kernel problems.
-
-config DEBUG_STACKOVERFLOW
-	bool "Check for stack overflows"
-	depends on DEBUG_KERNEL
-
-config DEBUG_STACK_USAGE
-	bool "Stack utilization instrumentation"
-	depends on DEBUG_KERNEL
-	help
-	  Enables the display of the minimum amount of free stack which each
-	  task has ever had available in the sysrq-T and sysrq-P debug output.
-
-	  This option will slow down process creation somewhat.
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to have the kernel do limited verification on memory
-	  allocation as well as poisoning memory on free to catch use of freed
-	  memory.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	depends on DEBUG_KERNEL
-	help
-	  If you say Y here, you will have some control over the system even
-	  if the system crashes for example during kernel debugging (e.g., you
-	  will be able to flush the buffer cache to disk, reboot the system
-	  immediately or dump some status information). This is accomplished
-	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
-	  also works on a serial console (on PC hardware at least), if you
-	  send a BREAK and then within 5 seconds a command keypress. The
-	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
-	  unless you really know what this hack does.
-
-config DEBUGGER
-	bool "Enable debugger hooks"
-	depends on DEBUG_KERNEL
-	help
-	  Include in-kernel hooks for kernel debuggers. Unless you are
-	  intending to debug the kernel, say N here.
-
-config XMON
-	bool "Include xmon kernel debugger"
-	depends on DEBUGGER
-	help
-	  Include in-kernel hooks for the xmon kernel monitor/debugger.
-	  Unless you are intending to debug the kernel, say N here.
-
-config XMON_DEFAULT
-	bool "Enable xmon by default"
-	depends on XMON
-
-config PPCDBG
-	bool "Include PPCDBG realtime debugging"
-	depends on DEBUG_KERNEL
-
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	help
-          If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  If you don't debug the kernel, you can say N.
-	  
+source "lib/Kconfig.debug"
+source "arch/ppc64/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/ppc64/Kconfig.debug linux-266-rc1-kdebug/arch/ppc64/Kconfig.debug
--- linux-266-rc1-pv/arch/ppc64/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/ppc64/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,27 @@
+
+menu "PPC64 kernel hacking"
+
+config DEBUGGER
+	bool "Enable debugger hooks"
+	depends on DEBUG_KERNEL
+	help
+	  Include in-kernel hooks for kernel debuggers. Unless you are
+	  intending to debug the kernel, say N here.
+
+config XMON
+	bool "Include xmon kernel debugger"
+	depends on DEBUGGER
+	help
+	  Include in-kernel hooks for the xmon kernel monitor/debugger.
+	  Unless you are intending to debug the kernel, say N here.
+
+config XMON_DEFAULT
+	bool "Enable xmon by default"
+	depends on XMON
+
+config PPCDBG
+	bool "Include PPCDBG realtime debugging"
+	depends on DEBUG_KERNEL
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/s390/Kconfig.debug linux-266-rc1-kdebug/arch/s390/Kconfig.debug
--- linux-266-rc1-pv/arch/s390/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/s390/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,5 @@
+
+menu "S/390 kernel hacking"
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/sh/Kconfig.debug linux-266-rc1-kdebug/arch/sh/Kconfig.debug
--- linux-266-rc1-pv/arch/sh/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/sh/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,111 @@
+
+menu "SuperH kernel hacking"
+
+config SH_STANDARD_BIOS
+	bool "Use LinuxSH standard BIOS"
+	help
+	  Say Y here if your target has the gdb-sh-stub
+	  package from www.m17n.org (or any conforming standard LinuxSH BIOS)
+	  in FLASH or EPROM.  The kernel will use standard BIOS calls during
+	  boot for various housekeeping tasks (including calls to read and
+	  write characters to a system console, get a MAC address from an
+	  on-board Ethernet interface, and shut down the hardware).  Note this
+	  does not work with machines with an existing operating system in
+	  mask ROM and no flash (WindowsCE machines fall in this category).
+	  If unsure, say N.
+
+config SH_EARLY_PRINTK
+	bool "Early printk support"
+	depends on SH_STANDARD_BIOS
+	help
+	  Say Y here to redirect kernel printk messages to the serial port
+	  used by the SH-IPL bootloader, starting very early in the boot
+	  process and ending when the kernel's serial console is initialised.
+	  This option is only useful porting the kernel to a new machine,
+	  when the kernel may crash or hang before the serial console is
+	  initialised. If unsure, say N.
+
+config KGDB
+	bool "Include KGDB kernel debugger"
+	help
+	  Include in-kernel hooks for kgdb, the Linux kernel source level
+	  debugger.  See <http://kgdb.sourceforge.net/> for more information.
+	  Unless you are intending to debug the kernel, say N here.
+
+menu "KGDB configuration options"
+	depends on KGDB
+
+config MORE_COMPILE_OPTIONS
+	bool "Add any additional compile options"
+	help
+	  If you want to add additional CFLAGS to the kernel build, enable this
+	  option and then enter what you would like to add in the next question.
+	  Note however that -g is already appended with the selection of KGDB.
+
+config COMPILE_OPTIONS
+	string "Additional compile arguments"
+	depends on MORE_COMPILE_OPTIONS
+
+config KGDB_NMI
+	bool "Enter KGDB on NMI"
+	default n
+
+config KGDB_THREAD
+	bool "Include KGDB thread support"
+	default y
+
+config SH_KGDB_CONSOLE
+	bool "Console messages through GDB"
+	default n
+
+config KGDB_SYSRQ
+	bool "Allow SysRq 'G' to enter KGDB"
+	default y
+
+config KGDB_KERNEL_ASSERTS
+	bool "Include KGDB kernel assertions"
+	default n
+
+comment "Serial port setup"
+
+config KGDB_DEFPORT
+	int "Port number (ttySCn)"
+	default "1"
+
+config KGDB_DEFBAUD
+	int "Baud rate"
+	default "115200"
+
+choice
+	prompt "Parity"
+	depends on KGDB
+	default KGDB_DEFPARITY_N
+
+config KGDB_DEFPARITY_N
+	bool "None"
+
+config KGDB_DEFPARITY_E
+	bool "Even"
+
+config KGDB_DEFPARITY_O
+	bool "Odd"
+
+endchoice
+
+choice
+	prompt "Data bits"
+	depends on KGDB
+	default KGDB_DEFBITS_8
+
+config KGDB_DEFBITS_8
+	bool "8"
+
+config KGDB_DEFBITS_7
+	bool "7"
+
+endchoice
+
+endmenu
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/sparc/Kconfig.debug linux-266-rc1-kdebug/arch/sparc/Kconfig.debug
--- linux-266-rc1-pv/arch/sparc/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/sparc/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,13 @@
+
+menu "SPARC kernel hacking"
+
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting (adds 70K)"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to make BUG() panics output the file name and line number
+	  of the BUG call as well as the EIP and oops trace.  This aids
+	  debugging but costs about 70-100K of memory.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/sparc64/Kconfig.debug linux-266-rc1-kdebug/arch/sparc64/Kconfig.debug
--- linux-266-rc1-pv/arch/sparc64/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/sparc64/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,38 @@
+
+menu "UltraSPARC kernel hacking"
+
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting (adds 70K)"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to make BUG() panics output the file name and line number
+	  of the BUG call as well as the EIP and oops trace.  This aids
+	  debugging but costs about 70-100K of memory.
+
+config DEBUG_DCFLUSH
+	bool "D-cache flush debugging"
+	depends on DEBUG_KERNEL
+
+config STACK_DEBUG
+	depends on DEBUG_KERNEL
+	bool "Stack Overflow Detection Support"
+
+config DEBUG_BOOTMEM
+	depends on DEBUG_KERNEL
+	bool "Debug BOOTMEM initialization"
+
+# We have a custom atomic_dec_and_lock() implementation but it's not
+# compatible with spinlock debugging so we need to fall back on
+# the generic version in that case.
+config HAVE_DEC_LOCK
+	bool
+	depends on SMP && !DEBUG_SPINLOCK
+	default y
+
+config MCOUNT
+	bool
+	depends on STACK_DEBUG
+	default y
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/um/Kconfig linux-266-rc1-kdebug/arch/um/Kconfig
--- linux-266-rc1-pv/arch/um/Kconfig	2004-04-15 14:00:11.000000000 -0700
+++ linux-266-rc1-kdebug/arch/um/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -102,10 +102,6 @@ config MCONSOLE
 
         It is safe to say 'Y' here.
 
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	depends on MCONSOLE
-
 config HOST_2G_2G
 	bool "2G/2G host address space split"
 
@@ -213,59 +209,8 @@ source "drivers/md/Kconfig"
 
 source "drivers/mtd/Kconfig"
 
-
 menu "Kernel hacking"
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-
-config DEBUG_SPINLOCK
-	bool "Debug spinlocks usage"
-
-config DEBUG_INFO
-	bool "Enable kernel debugging symbols"
-	help
-        When this is enabled, the User-Mode Linux binary will include
-        debugging symbols.  This enlarges the binary by a few megabytes,
-        but aids in tracking down kernel problems in UML.  It is required
-        if you intend to do any kernel development.
-
-        If you're truly short on disk space or don't expect to report any
-        bugs back to the UML developers, say N, otherwise say Y.
-
-config FRAME_POINTER
-	bool
-	default y if DEBUG_INFO
-
-config PT_PROXY
-	bool "Enable ptrace proxy"
-	depends on XTERM_CHAN && DEBUG_INFO
-
-config GPROF
-	bool "Enable gprof support"
-	depends on DEBUG_INFO
-	help
-        This allows profiling of a User-Mode Linux kernel with the gprof
-        utility.
-
-        See <http://user-mode-linux.sourceforge.net/gprof.html> for more
-        details.
-
-        If you're involved in UML kernel development and want to use gprof,
-        say Y.  If you're unsure, say N.
-
-config GCOV
-	bool "Enable gcov support"
-	depends on DEBUG_INFO
-	help
-        This option allows developers to retrieve coverage data from a UML
-        session.
-
-        See <http://user-mode-linux.sourceforge.net/gprof.html> for more
-        details.
-
-        If you're involved in UML kernel development and want to use gcov,
-        say Y.  If you're unsure, say N.
-
+source "lib/Kconfig.debug"
+source "arch/um/Kconfig.debug"
 endmenu
 
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/um/Kconfig.debug linux-266-rc1-kdebug/arch/um/Kconfig.debug
--- linux-266-rc1-pv/arch/um/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/um/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,35 @@
+
+menu "UML kernel hacking"
+
+config PT_PROXY
+	bool "Enable ptrace proxy"
+	depends on XTERM_CHAN && DEBUG_INFO
+
+config GPROF
+	bool "Enable gprof support"
+	depends on DEBUG_INFO
+	help
+        This allows profiling of a User-Mode Linux kernel with the gprof
+        utility.
+
+        See <http://user-mode-linux.sourceforge.net/gprof.html> for more
+        details.
+
+        If you're involved in UML kernel development and want to use gprof,
+        say Y.  If you're unsure, say N.
+
+config GCOV
+	bool "Enable gcov support"
+	depends on DEBUG_INFO
+	help
+        This option allows developers to retrieve coverage data from a UML
+        session.
+
+        See <http://user-mode-linux.sourceforge.net/gprof.html> for more
+        details.
+
+        If you're involved in UML kernel development and want to use gcov,
+        say Y.  If you're unsure, say N.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/v850/Kconfig.debug linux-266-rc1-kdebug/arch/v850/Kconfig.debug
--- linux-266-rc1-pv/arch/v850/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/v850/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,10 @@
+
+menu "V850 kernel hacking"
+
+config NO_KERNEL_MSG
+	bool "Suppress Kernel BUG Messages"
+	help
+	  Do not output any debug BUG messages within the kernel.
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/x86_64/Kconfig linux-266-rc1-kdebug/arch/x86_64/Kconfig
--- linux-266-rc1-pv/arch/x86_64/Kconfig	2004-04-15 14:00:11.000000000 -0700
+++ linux-266-rc1-kdebug/arch/x86_64/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -410,104 +410,8 @@ source fs/Kconfig
 source "arch/x86_64/oprofile/Kconfig"
 
 menu "Kernel hacking"
-
-config DEBUG_KERNEL
-	bool "Kernel debugging"
-	help
-	  Say Y here if you are developing drivers or trying to debug and
-	  identify kernel problems.
-
-config DEBUG_SLAB
-	bool "Debug memory allocations"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here to have the kernel do limited verification on memory
-	  allocation as well as poisoning memory on free to catch use of freed
-	  memory.
-
-config MAGIC_SYSRQ
-	bool "Magic SysRq key"
-	help
-	  If you say Y here, you will have some control over the system even
-	  if the system crashes for example during kernel debugging (e.g., you
-	  will be able to flush the buffer cache to disk, reboot the system
-	  immediately or dump some status information). This is accomplished
-	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
-	  also works on a serial console (on PC hardware at least), if you
-	  send a BREAK and then within 5 seconds a command keypress. The
-	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
-	  unless you really know what this hack does.
-
-config DEBUG_SPINLOCK
-	bool "Spinlock debugging"
-	depends on DEBUG_KERNEL
-	help
-	  Say Y here and build SMP to catch missing spinlock initialization
-	  and certain other kinds of spinlock errors commonly made.  This is
-	  best used in conjunction with the NMI watchdog so that spinlock
-	  deadlocks are also debuggable.
-
-# !SMP for now because the context switch early causes GPF in segment reloading
-# and the GS base checking does the wrong thing then, causing a hang.
-config CHECKING
-	bool "Additional run-time checks"
-	depends on DEBUG_KERNEL && !SMP
-	help
-	  Enables some internal consistency checks for kernel debugging.
-	  You should normally say N.
-
-config INIT_DEBUG
-	bool "Debug __init statements"
-	depends on DEBUG_KERNEL
-	help
-	  Fill __init and __initdata at the end of boot. This helps debugging
-	  illegal uses of __init and __initdata after initialization.	  
-
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	help
-          If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  Please note that this option requires new binutils.
-	  If you don't debug the kernel, you can say N.
-	  
-config FRAME_POINTER
-       bool "Compile the kernel with frame pointers"
-       help
-	 Compile the kernel with frame pointers. This may help for some 
-	 debugging with external debuggers. Note the standard oops backtracer 
-	 doesn't make use of this  and the x86-64 kernel doesn't ensure an consistent
-	 frame pointer through inline assembly (semaphores etc.)
-	 Normally you should say N.
-
-config IOMMU_DEBUG
-       depends on GART_IOMMU && DEBUG_KERNEL
-       bool "Enable IOMMU debugging"
-       help
-         Force the IOMMU to on even when you have less than 4GB of
-	 memory and add debugging code. On overflow always panic. And
-	 allow to enable IOMMU leak tracing. Can be disabled at boot
-	 time with iommu=noforce. This will also enable scatter gather
-	 list merging.  Currently not recommended for production
-	 code. When you use it make sure you have a big enough
-	 IOMMU/AGP aperture.  Most of the options enabled by this can
-	 be set more finegrained using the iommu= command line
-	 options. See Documentation/x86_64/boot-options.txt for more
-	 details.
-
-config IOMMU_LEAK
-       bool "IOMMU leak tracing"
-       depends on DEBUG_KERNEL
-       depends on IOMMU_DEBUG
-       help
-         Add a simple leak tracer to the IOMMU code. This is useful when you
-	 are debugging a buggy device driver that leaks IOMMU mappings.
-       
-#config X86_REMOTE_DEBUG
-#       bool "kgdb debugging stub"
-
+source "lib/Kconfig.debug"
+source "arch/x86_64/Kconfig.debug"
 endmenu
 
 source "security/Kconfig"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/arch/x86_64/Kconfig.debug linux-266-rc1-kdebug/arch/x86_64/Kconfig.debug
--- linux-266-rc1-pv/arch/x86_64/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/arch/x86_64/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,47 @@
+
+menu "X86-64 kernel hacking"
+
+# !SMP for now because the context switch early causes GPF in segment reloading
+# and the GS base checking does the wrong thing then, causing a hang.
+config CHECKING
+	bool "Additional run-time checks"
+	depends on DEBUG_KERNEL && !SMP
+	help
+	  Enables some internal consistency checks for kernel debugging.
+	  You should normally say N.
+
+config INIT_DEBUG
+	bool "Debug __init statements"
+	depends on DEBUG_KERNEL
+	help
+	  Fill __init and __initdata at the end of boot. This helps debugging
+	  illegal uses of __init and __initdata after initialization.	  
+
+config IOMMU_DEBUG
+       depends on GART_IOMMU && DEBUG_KERNEL
+       bool "Enable IOMMU debugging"
+       help
+         Force the IOMMU to on even when you have less than 4GB of
+	 memory and add debugging code. On overflow always panic. And
+	 allow to enable IOMMU leak tracing. Can be disabled at boot
+	 time with iommu=noforce. This will also enable scatter gather
+	 list merging.  Currently not recommended for production
+	 code. When you use it make sure you have a big enough
+	 IOMMU/AGP aperture.  Most of the options enabled by this can
+	 be set more finegrained using the iommu= command line
+	 options. See Documentation/x86_64/boot-options.txt for more
+	 details.
+
+config IOMMU_LEAK
+       bool "IOMMU leak tracing"
+       depends on DEBUG_KERNEL
+       depends on IOMMU_DEBUG
+       help
+         Add a simple leak tracer to the IOMMU code. This is useful when you
+	 are debugging a buggy device driver that leaks IOMMU mappings.
+       
+#config X86_REMOTE_DEBUG
+#       bool "kgdb debugging stub"
+
+endmenu
+
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/init/Kconfig linux-266-rc1-kdebug/init/Kconfig
--- linux-266-rc1-pv/init/Kconfig	2004-04-15 14:00:13.000000000 -0700
+++ linux-266-rc1-kdebug/init/Kconfig	2004-04-15 14:00:56.000000000 -0700
@@ -227,14 +227,6 @@ menuconfig EMBEDDED
           environments which can tolerate a "non-standard" kernel.
           Only use this if you really know what you are doing.
 
-config KALLSYMS
-	 bool "Load all symbols for debugging/kksymoops" if EMBEDDED
-	 default y
-	 help
-	   Say Y here to let the kernel print out symbolic crash information and
-	   symbolic stack backtraces. This increases the size of the kernel
-	   somewhat, as all symbols have to be loaded into the kernel image.
-
 config FUTEX
 	bool "Enable futex support" if EMBEDDED
 	default y
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-rc1-pv/lib/Kconfig.debug linux-266-rc1-kdebug/lib/Kconfig.debug
--- linux-266-rc1-pv/lib/Kconfig.debug	1969-12-31 16:00:00.000000000 -0800
+++ linux-266-rc1-kdebug/lib/Kconfig.debug	2004-04-15 14:00:56.000000000 -0700
@@ -0,0 +1,151 @@
+
+menu "Generic kernel hacking"
+
+if !CRIS && !H8300
+
+config DEBUG_KERNEL
+	bool "Kernel debugging"
+	default y if USERMODE
+	help
+	  Say Y here if you are developing drivers or trying to debug and
+	  identify kernel problems.
+
+config MAGIC_SYSRQ
+	bool "Magic SysRq key" if !CRIS
+	depends on DEBUG_KERNEL || MCONSOLE
+	help
+	  If you say Y here, you will have some control over the system even
+	  if the system crashes for example during kernel debugging (e.g., you
+	  will be able to flush the buffer cache to disk, reboot the system
+	  immediately or dump some status information). This is accomplished
+	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
+	  also works on a serial console (on PC hardware at least), if you
+	  send a BREAK and then within 5 seconds a command keypress. The
+	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
+	  unless you really know what this hack does.
+
+config KALLSYMS
+	 bool "Load all symbols for debugging/kksymoops" if EMBEDDED
+	 default y if !ARCH_S390
+	 help
+	   Say Y here to let the kernel print out symbolic crash information and
+	   symbolic stack backtraces. This increases the size of the kernel
+	   somewhat, as all symbols have to be loaded into the kernel image.
+
+if X86 || X86_64 || MACH_DECSTATION || ALPHA_GENERIC || ALPHA_SRM || PPC64
+
+config EARLY_PRINTK
+	bool "Early printk" if EMBEDDED
+	default y
+	help
+	  Write kernel log output directly into the VGA buffer or to a serial
+	  port.
+
+	  This is useful for kernel debugging when your machine crashes very
+	  early before the console code is initialized. For normal operation
+	  it is not recommended because it looks ugly and doesn't cooperate
+	  with klogd/syslogd or the X server. You should normally N here,
+	  unless you want to debug such a crash.
+
+endif
+
+config DEBUG_STACKOVERFLOW
+	bool "Check for stack overflows"
+	depends on DEBUG_KERNEL && !ALPHA
+
+config DEBUG_STACK_USAGE
+	bool "Stack utilization instrumentation"
+	depends on DEBUG_KERNEL && !ALPHA
+	help
+	  Enables the display of the minimum amount of free stack which each
+	  task has ever had available in the sysrq-T and sysrq-P debug output.
+
+	  This option will slow down process creation somewhat.
+
+config DEBUG_SLAB
+	bool "Debug memory allocations"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here to have the kernel do limited verification on memory
+	  allocation as well as poisoning memory on free to catch use of freed
+	  memory.
+
+config DEBUG_SPINLOCK
+	bool "Spinlock debugging"
+	depends on DEBUG_KERNEL
+	help
+	  Say Y here and build SMP to catch missing spinlock initialization
+	  and certain other kinds of spinlock errors commonly made.  This is
+	  best used in conjunction with the NMI watchdog so that spinlock
+	  deadlocks are also debuggable.
+
+config DEBUG_PAGEALLOC
+	bool "Page alloc debugging"
+	depends on DEBUG_KERNEL
+	help
+	  Unmap pages from the kernel linear mapping after free_pages().
+	  This results in a large slowdown, but helps to find certain types
+	  of memory corruptions.
+
+config DEBUG_HIGHMEM
+	bool "Highmem debugging"
+	depends on DEBUG_KERNEL && HIGHMEM
+	help
+	  This options enables addition error checking for high memory systems.
+	  Disable for production systems.
+
+config DEBUG_INFO
+	bool "Compile the kernel with debug info"
+	depends on DEBUG_KERNEL
+	help
+          If you say Y here the resulting kernel image will include
+	  debugging info resulting in a larger kernel image.
+	  Say Y here only if you plan to use gdb to debug the kernel.
+	  If you don't debug the kernel, you can say N.
+	  
+config DEBUG_SPINLOCK_SLEEP
+	bool "Sleep-inside-spinlock checking"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, various routines which may sleep will become very
+	  noisy if they are called with a spinlock held.	
+
+if !ARM && !ARM26 && !X86_64
+config FRAME_POINTER
+	bool "Compile the kernel with frame pointers"
+	default y if (SUPERH && KGDB) || (USERMODE && DEBUG_INFO)
+	help
+	  If you say Y here the resulting kernel image will be slightly larger
+	  and slower, but it will give very useful debugging information.
+	  If you don't debug the kernel, you can say N, but we may not be able
+	  to solve problems without frame pointers.
+endif
+if X86_64
+config FRAME_POINTER
+	bool "Compile the kernel with frame pointers"
+	help
+	  If you say Y here the resulting kernel image will be slightly larger
+	  and slower, but it will give very useful debugging information.
+	  If you don't debug the kernel, you can say N, but we may not be able
+	  to solve problems without frame pointers.
+	  This may help for some debugging with external debuggers.
+	  Note the standard oops backtracer doesn't make use of this and
+	  the x86-64 kernel doesn't ensure a consistent
+	  frame pointer through inline assembly (semaphores etc.)
+	  Normally you should say N.
+endif
+
+config 4KSTACKS
+	bool "Use 4Kb for kernel stacks instead of 8Kb"
+	help
+	  If you say Y here the kernel will use a 4Kb stacksize for the
+	  kernel stack attached to each process/thread. This facilitates
+	  running more threads on a system and also reduces the pressure
+	  on the VM subsystem for higher order allocations. This option
+	  will also use IRQ stacks to compensate for the reduced stackspace.
+
+endif
+#end for !CRIS && !H8300
+
+endmenu
+

Re: PATCH] Kconfig.debug family

[Sam Ravnborg]

On Thu, Apr 15, 2004 at 01:52:29PM -0700, Randy.Dunlap wrote:
> On Wed, 14 Apr 2004 16:25:39 -0500 Matt Mackall wrote:
> 
> | Sticking this in arch/*/Kconfig seems silly (as does much of the
> | duplication in said files). Can we stick this and other debug bits
> | under the kallsyms option in init/Kconfig instead? Or alternately move
> | debugging bits into their own file that gets included as appropriate.
> 
> 
> This patch:
> - creates lib/Kconfig.debug for generic kernel debug options
> - creates arch/*/Kconfig.debug for arch-specific debug options
> - moves KALLSYMS to the generic kernel debug options list
> 
> 
> This is a first cut for review/comments.  I will double-check
> the generic options list to see how it needs to be corrected...

Looks good to me - and I really like concentrating this in
a more logic common place.

If you could move even more to the generic part it would be fine.

	Sam

Re: PATCH] Kconfig.debug family

[Marc-Christian Petersen]

On Thursday 15 April 2004 22:52, Randy.Dunlap wrote:

Hi Randy,

> This patch:
> - creates lib/Kconfig.debug for generic kernel debug options
> - creates arch/*/Kconfig.debug for arch-specific debug options
> - moves KALLSYMS to the generic kernel debug options list
> This is a first cut for review/comments.  I will double-check
> the generic options list to see how it needs to be corrected...

I really appreciate it. But I have one comment/suggestion:

We might use lib/Kconfig.debug for all arches and use proper "depend on" if 
there is stuff for some specific arch only. So we have every debug stuff just 
in one file. What do you think?

ciao, Marc

Re: PATCH] Kconfig.debug family

[Randy.Dunlap]

On Thu, 15 Apr 2004 23:36:30 +0200 Marc-Christian Petersen wrote:

| On Thursday 15 April 2004 22:52, Randy.Dunlap wrote:
| 
| Hi Randy,
| 
| > This patch:
| > - creates lib/Kconfig.debug for generic kernel debug options
| > - creates arch/*/Kconfig.debug for arch-specific debug options
| > - moves KALLSYMS to the generic kernel debug options list
| > This is a first cut for review/comments.  I will double-check
| > the generic options list to see how it needs to be corrected...
| 
| I really appreciate it. But I have one comment/suggestion:
| 
| We might use lib/Kconfig.debug for all arches and use proper "depend on" if 
| there is stuff for some specific arch only. So we have every debug stuff just 
| in one file. What do you think?

Hi Marc,

That sounds like my first version (unposted), which failed IMO.
It looks OK if you/user does not enable viewing all flags/options
(in [xg]config -- I used xconfig).  However, if those options are
enabled, you/user sees all config options for all architectures,
and I didn't find that acceptable.  Feel free to disagree with me
and persuade me otherwise, because having them *all* in
lib/Kconfig.debug is nicer IMO.

The full patch to do this (against 2.6.5-bk2) is now available at:
http://developer.osdl.org/rddunlap/patches/kconfig_debug_265bk2.patch

if you or anyone else wants to compare how they look.

Thanks,
--
~Randy

Re: [PATCH] conditionalize some boring buffer_head checks

[Tim Hockin]

Somewhat off the original topic, but am I the only one who finds it weird
(and error-prone) that you have to add the same KConfig to a dozen or more
Kconfig files?

Shouldn't there be a KConfig libe, and all you need to do for the arch is
reference the CONFIG_FOO from the lib?  Would at least save all the
duplicate strings and definitions...

Kconfig.lib:
	config DEBUG_BUFFERS
		bool "Enable additional filesystem buffer_head checks"
		depends on DEBUG_KERNEL
		help
		  If you say Y here, additional checks are performed that
		  aid filesystem development.

arch/*/Kconfig
	libpath /Kconfig.lib
	...
	insert DEBUG_BUFFERS
	...

If the inserted symbol is not found in the Kconfig libpath, error out.
You can then break debug Kconfigs into a separate lib file, etc.  Maybe
that's too far, but you get the idea?

Sorry, just a nit that bothers me.

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

Tim Hockin wrote:
> Somewhat off the original topic, but am I the only one who finds it weird
> (and error-prone) that you have to add the same KConfig to a dozen or more
> Kconfig files?
> 
> Shouldn't there be a KConfig libe, and all you need to do for the arch is
> reference the CONFIG_FOO from the lib?  Would at least save all the
> duplicate strings and definitions...
> 
> Kconfig.lib:
> 	config DEBUG_BUFFERS
> 		bool "Enable additional filesystem buffer_head checks"
> 		depends on DEBUG_KERNEL
> 		help
> 		  If you say Y here, additional checks are performed that
> 		  aid filesystem development.
> 
> arch/*/Kconfig
> 	libpath /Kconfig.lib
> 	...
> 	insert DEBUG_BUFFERS
> 	...


Seems a lot easier just to gather the common definitions into a Kconfig 
file, and include it via the standard 'source' directive.

	Jeff

Re: [PATCH] conditionalize some boring buffer_head checks

[Chris Friesen]

Jeff Garzik wrote:
> Tim Hockin wrote:
> 
>> Somewhat off the original topic, but am I the only one who finds it weird
>> (and error-prone) that you have to add the same KConfig to a dozen or 
>> more
>> Kconfig files?
>>
>> Shouldn't there be a KConfig libe, and all you need to do for the arch is
>> reference the CONFIG_FOO from the lib?  Would at least save all the
>> duplicate strings and definitions...

> Seems a lot easier just to gather the common definitions into a Kconfig 
> file, and include it via the standard 'source' directive.

Either way, I personally would be extremely grateful for some kind of 
standard way to add a new configurable generic feature to every 
architecture.  I'm tired of having to add it manually.  I hadn't 
realized about the "source" feature--seems like we should be able to 
pull a lot of stuff into something like that even now.

On a side note, why is there no Kconfig for the "kernel" directory?

Chris

Re: [PATCH] conditionalize some boring buffer_head checks

[Randy.Dunlap]

On Wed, 14 Apr 2004 09:31:50 -0400 Chris Friesen wrote:

| Jeff Garzik wrote:
| > Tim Hockin wrote:
| > 
| >> Somewhat off the original topic, but am I the only one who finds it weird
| >> (and error-prone) that you have to add the same KConfig to a dozen or 
| >> more
| >> Kconfig files?
| >>
| >> Shouldn't there be a KConfig libe, and all you need to do for the arch is
| >> reference the CONFIG_FOO from the lib?  Would at least save all the
| >> duplicate strings and definitions...
| 
| > Seems a lot easier just to gather the common definitions into a Kconfig 
| > file, and include it via the standard 'source' directive.
| 
| Either way, I personally would be extremely grateful for some kind of 
| standard way to add a new configurable generic feature to every 
| architecture.  I'm tired of having to add it manually.  I hadn't 
| realized about the "source" feature--seems like we should be able to 
| pull a lot of stuff into something like that even now.
| 
| On a side note, why is there no Kconfig for the "kernel" directory?

Use init/Kconfig for that.

--
~Randy
"We have met the enemy and he is us."  -- Pogo (by Walt Kelly)
(Again.  Sometimes I think ln -s /usr/src/linux/.config .signature)

Re: [PATCH] conditionalize some boring buffer_head checks

[Jens Axboe]

On Wed, Apr 14 2004, Jeff Garzik wrote:
> 
> These checks are executed billions of times per day, with no stack dump 
> bug reports sent to lkml.  Arguably, they will only trigger on buggy 
> filesystems (programmer error), and thus IMO shouldn't even be executed 
> in a non-debug kernel.
> 
> Even though BUG_ON() includes unlikely(), I think this patch -- or 
> something like it -- is preferable.  The buffer_error() checks aren't 
> even marked unlikely().
> 
> This is a micro-optimization on a key kernel fast path.

As Andrew mentioned, this isn't a fast path at all. You are potentially
even going to block on this call, and even if you don't you'll end up
spending a butt load of cycles in the io scheduler.

> ===== fs/buffer.c 1.237 vs edited =====
> --- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
> +++ edited/fs/buffer.c	Wed Apr 14 03:39:15 2004
> @@ -2688,6 +2688,7 @@
>  {
>  	struct bio *bio;
>  
> +#ifdef BH_DEBUG
>  	BUG_ON(!buffer_locked(bh));
>  	BUG_ON(!buffer_mapped(bh));
>  	BUG_ON(!bh->b_end_io);

The last one will be 'caught' at the other end of io completion, so I
guess that could be killed (even though you already lost the context of
the error, then). The first two are buffer state errors, I think those
should be kept unconditionally.

> @@ -2698,6 +2699,7 @@
>  		buffer_error();
>  	if (rw == READ && buffer_dirty(bh))
>  		buffer_error();
> +#endif

I'm fine with killing the buffer_error(), maybe

	if (rw == WRITE && !buffer_uptodate(bh))
		buffer_error();

should be kept though.

-- 
Jens Axboe

Re: [PATCH] conditionalize some boring buffer_head checks

[Jeff Garzik]

Jens Axboe wrote:
> On Wed, Apr 14 2004, Jeff Garzik wrote:
>>===== fs/buffer.c 1.237 vs edited =====
>>--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
>>+++ edited/fs/buffer.c	Wed Apr 14 03:39:15 2004
>>@@ -2688,6 +2688,7 @@
>> {
>> 	struct bio *bio;
>> 
>>+#ifdef BH_DEBUG
>> 	BUG_ON(!buffer_locked(bh));
>> 	BUG_ON(!buffer_mapped(bh));
>> 	BUG_ON(!bh->b_end_io);
> 
> 
> The last one will be 'caught' at the other end of io completion, so I
> guess that could be killed (even though you already lost the context of
> the error, then). The first two are buffer state errors, I think those
> should be kept unconditionally.
> 
> 
>>@@ -2698,6 +2699,7 @@
>> 		buffer_error();
>> 	if (rw == READ && buffer_dirty(bh))
>> 		buffer_error();
>>+#endif
> 
> 
> I'm fine with killing the buffer_error(), maybe
> 
> 	if (rw == WRITE && !buffer_uptodate(bh))
> 		buffer_error();
> 
> should be kept though.


Well, all of these are buffer state (and programmer) errors...

	Jeff

Re: [PATCH] conditionalize some boring buffer_head checks

[Jens Axboe]

On Wed, Apr 14 2004, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Wed, Apr 14 2004, Jeff Garzik wrote:
> >>===== fs/buffer.c 1.237 vs edited =====
> >>--- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
> >>+++ edited/fs/buffer.c	Wed Apr 14 03:39:15 2004
> >>@@ -2688,6 +2688,7 @@
> >>{
> >>	struct bio *bio;
> >>
> >>+#ifdef BH_DEBUG
> >>	BUG_ON(!buffer_locked(bh));
> >>	BUG_ON(!buffer_mapped(bh));
> >>	BUG_ON(!bh->b_end_io);
> >
> >
> >The last one will be 'caught' at the other end of io completion, so I
> >guess that could be killed (even though you already lost the context of
> >the error, then). The first two are buffer state errors, I think those
> >should be kept unconditionally.
> >
> >
> >>@@ -2698,6 +2699,7 @@
> >>		buffer_error();
> >>	if (rw == READ && buffer_dirty(bh))
> >>		buffer_error();
> >>+#endif
> >
> >
> >I'm fine with killing the buffer_error(), maybe
> >
> >	if (rw == WRITE && !buffer_uptodate(bh))
> >		buffer_error();
> >
> >should be kept though.
> 
> 
> Well, all of these are buffer state (and programmer) errors...

Certainly, that is what they are meant to catch :-)

That's why I agree that some of them can be skipped, but I do think that
the ones I listed should be kept. It's an order of magnitude easier to
find and debug these errors if you are warned up front. I don't think
that saving those few cycles in an io submission path justifies that.

-- 
Jens Axboe