Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Steven Rostedt]

Hi Ingo,

I've found something that is very interesting and I can't explain it.


On Mon, 14 Mar 2005, Steven Rostedt wrote:
>
>
> On Mon, 14 Mar 2005, Steven Rostedt wrote:
> >
> > On Mon, 14 Mar 2005, Steven Rostedt wrote:
> > >
> > > I just downloaded -40 and applied my patch, compiled it with
> > > PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
> > > I'm getting the following...
> > >
> > > BUG: Unable to handle kernel NULL pointer dereference at virtual address
> > > 00000000
> > >  printing eip:
> > > c0213438
> > > *pde = 00000000
> >
> > [snip]
> >
> > >

All I did now was to add this patch to your -40-00 kernel:

diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h	2005-03-02 02:38:19.000000000 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h	2005-03-14 13:22:04.000000000 -0500
@@ -324,6 +324,8 @@
 	return bh->b_private;
 }

+BUFFER_FNS(JournalHead,journalhead)
+
 static inline void jbd_lock_bh_state(struct buffer_head *bh)
 {
 	bit_spin_lock(BH_State, &bh->b_state);



And I get the following output:

BUG: Unable to handle kernel NULL pointer dereference at virtual address
00000000
 printing eip:
c0213118
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: ipv6 af_packet tsdev mousedev evdev floppy psmouse
pcspkr snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug ehci_hcd
intel_agp agpgart uhci_hcd usbcore e100 mii ide_cd cdrom unix
CPU:    0
EIP:    0060:[<c0213118>]    Not tainted VLI
EFLAGS: 00010286   (2.6.11-RT-V0.7.40-00)
EIP is at vt_ioctl+0x18/0x1ab0
eax: 00000000   ebx: 00005603   ecx: 00005603   edx: cee14d80
esi: c0213100   edi: cb4bd000   ebp: cc03bf18   esp: cc03be48
ds: 007b   es: 007b   ss: 0068   preempt: 00000000
Process XFree86 (pid: 4709, threadinfo=cc03a000 task=cf0d5020)
Stack: cf0d5170 cc03a000 cf0d5020 c03448ec cf0d5020 00000246 cc03be7c
c0117267
       c03448f4 00000006 00000001 00000000 00000000 cc03bebc cf1b81ec
ce820600
       ce94a9b8 00000000 00000000 cc03bed4 c01704f1 ce94a9b8 00000007
00000000
Call Trace:
 [<c0103cdf>] show_stack+0x7f/0xa0 (28)
 [<c0103e95>] show_registers+0x165/0x1d0 (56)
 [<c0104088>] die+0xc8/0x150 (64)
 [<c01153c6>] do_page_fault+0x356/0x6c4 (216)
 [<c0103973>] error_code+0x2b/0x30 (268)
 [<c020e5fb>] tty_ioctl+0x34b/0x490 (52)
 [<c016807f>] do_ioctl+0x4f/0x70 (32)
 [<c0168282>] vfs_ioctl+0x62/0x1d0 (40)
 [<c0168451>] sys_ioctl+0x61/0x90 (40)
 [<c0102ec3>] syscall_call+0x7/0xb (-8124)
Code: ff ff 8d 05 28 4d 34 c0 e8 f6 60 0a 00 e9 3a ff ff ff 90 55 89 e5 57
56 53 81 ec c4 00 00 00 8b 7d 08 8b 5d 10 8b 87 7c 09 00 00 <8b> 30 89 34
24 8b 04 b5 e0 b7 3c c0 89 45 8c e8 a4 6a 00 00 85



I don't know why. BUFFER_FNS is just defined as:

#define BUFFER_FNS(bit, name)						\
static inline void set_buffer_##name(struct buffer_head *bh)		\
{									\
	set_bit(BH_##bit, &(bh)->b_state);				\
}									\
static inline void clear_buffer_##name(struct buffer_head *bh)		\
{									\
	clear_bit(BH_##bit, &(bh)->b_state);				\
}									\
static inline int buffer_##name(const struct buffer_head *bh)		\
{									\
	return test_bit(BH_##bit, &(bh)->b_state);			\
}

So all it does is make three function that are never used.

set_buffer_journalhead(...)
clear_buffer_journalhead(...)
buffer_journalhead(...)

Unless, some macro uses it, but I don't know why adding that line causes
the bug output that I showed.  If I remove that line, I don't get that
output.  And this is consistent. I've recompiled the kernel several
times, and everytime I compile it with this added patch I get that output.
And everytime without it, it runs fine.

Oh, please note that this only happens with PREEMPT_DESKTOP, and not with
PREEMPT_RT.

I really think this is a symptom of something else and not the cause of
the bug. What do you think?


-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/