From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266195AbUGPDKZ (ORCPT ); Thu, 15 Jul 2004 23:10:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266290AbUGPDKZ (ORCPT ); Thu, 15 Jul 2004 23:10:25 -0400 Received: from rproxy.gmail.com ([64.233.170.205]:18641 "HELO mproxy.gmail.com") by vger.kernel.org with SMTP id S266195AbUGPDKM (ORCPT ); Thu, 15 Jul 2004 23:10:12 -0400 Message-ID: Date: Thu, 15 Jul 2004 23:10:11 -0400 From: Dan Merillat To: linux-kernel@vger.kernel.org Subject: Bug report for Reiserfs on 2.6.4-rc2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I know 2.6.4-rc2 is old, but in case this hasn't already been found and fixed I got nailed by this. I'm using reiserfs un a logical volume, and I recently resized it (while it was having pretty hefty IO) I'm going to classify this as a "don't do that in the future" type bug. Also, I'm upgrading to latest kernel.org. So much for my 62 day uptime. :-) Unable to handle kernel NULL pointer dereference at virtual address 00000000 c01948ba *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 00000000 ebx: 00000000 ecx: 00000028 edx: d09db000 esi: d09db140 edi: 00001000 ebp: cb65bb68 esp: cb65bb14 ds: 007b es: 007b ss: 0068 Stack: cb65bdf8 cedabc00 cebe8db0 00000001 cb65bb58 c01b18f0 cecda630 00004d3e 00001000 00000002 cb65bb10 00000018 00004d3d cecb3000 00000000 cedabc00 00000000 00000000 00000028 cb65bba4 00001000 cb65bbb4 c0194f1f cb65bdf8 Call Trace: [] recalc_task_prio+0x8e/0x1b0 [] reiserfs_file_write+0x0/0x88d [] vfs_write+0xce/0x140 [] sys_write+0x3f/0x60 [] syscall_call+0x7/0xb Code: 8b 45 08 8b 40 10 89 45 e8 8b 1b 8b 80 6c 01 00 00 8b 50 08 89 5d e4 ff 80 e4 01 00 00 8d 34 ca 85 f6 0f 84 99 04 00 00 8b 46 04 <8b> 00 a8 04 0f 85 6d 04 00 00 8b 4d 10 0f b7 16 3b 11 0f 8f 55 Trace; c01b2250 Trace; c015da7b Trace; c019c474 Trace; c01b0f93 Trace; c01a326d Trace; c01a3870 Trace; c01a3e5c Trace; c011c2dc 6: 89 45 e8 mov %eax,0xffffffe8(%ebp) Code; c0194898 9: 8b 1b mov (%ebx),%ebx Code; c019489a b: 8b 80 6c 01 00 00 mov 0x16c(%eax),%eax Code; c01948a0 11: 8b 50 08 mov 0x8(%eax),%edx Code; c01948a3 14: 89 5d e4 mov %ebx,0xffffffe4(%ebp) Code; c01948a6 17: ff 80 e4 01 00 00 incl 0x1e4(%eax) Code; c01948ac 1d: 8d 34 ca lea (%edx,%ecx,8),%esi Code; c01948af 20: 85 f6 test %esi,%esi Code; c01948b1 22: 0f 84 99 04 00 00 je 4c1 <_EIP+0x4c1> Code; c01948b7 28: 8b 46 04 mov 0x4(%esi),%eax /140> Trace; c011c11e Trace; c01a3870 Trace; c015893e Trace; c0158a4f Trace; c041caeb This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019488f 00000000 <_EIP>: Code; c019488f 0: 8b 45 08 mov 0x8(%ebp),%eax Code; c0194892 3: 8b 40 10 mov 0x10(%eax),%eax >>EIP; c01948ba <===== >>edx; d09db000 >>esi; d09db140 >>ebp; cb65bb68 >>esp; cb65bb14 Trace; c01b18f0 Trace; c0194f1f Trace; c0195976 Trace; c01b9ad7 Trace; c01a1740 Trace; c01b1262 [] search_by_key+0x680/0xe40 [] scan_bitmap+0x1af/0x220 [] reiserfs_allocate_blocknrs+0x1e6/0x7d0 [] journal_begin+0x27/0x30 [] reiserfs_allocate_blocks_for_region+0x1c0/0x14b0 [] is_tree_node+0x62/0x70 [] search_for_position_by_key+0x1a0/0x3c0 [] alloc_buffer_head+0x3b/0x60 [] make_cpu_key+0x54/0x60 [] pathrelse+0x23/0x40 [] reiserfs_prepare_file_region_for_write+0x36d/0x970 [] reiserfs_file_write+0x0/0x88d [] reiserfs_file_write+0x5ec/0x88d [] try_to_wake_up+0x9c/0x140