From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 15 Apr 2002 21:17:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 15 Apr 2002 21:17:21 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.101]:63440 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id ; Mon, 15 Apr 2002 21:17:20 -0400 Message-ID: <3CBB7B73.8090104@us.ibm.com> Date: Mon, 15 Apr 2002 18:16:35 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Viro CC: Andrew Morton , linux-kernel@vger.kernel.org Subject: OOPS caused by ext2 changes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton and I discused this earlier. I have some more information now. The problem: "dbench 64" run on a small (~120meg) partition with 1k block sizes produces Oopses. This changeset: http://linus.bkbits.net:8080/linux-2.5/patch@1.248.2.6?nav=index.html|ChangeSet|cset@1.248.2.6 is the culprit. Without it applied, none of this happens. The errors: VFS: brelse: Trying to free free buffer EXT2-fs error (device sd(8,6)): ext2_free_blocks: bit already cleared for block 101078 EXT2-fs error (device sd(8,6)): ext2_free_blocks: bit already cleared for block 101077 Then, follows it up with a bunch of Oopses. I've included two of them below, but it looks to me like the buffer_head chain is getting changed unexpectedly. for instance, this: do { bh->b_end_io = NULL; tail = bh; bh = bh->b_this_page; } while (bh); Oopses when bh is set to something invalid. I can reproduce these pretty easily. They still happen in 2.5.8. Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 02000820 ebx: c4aadbe8 ecx: 02000820 edx: 00000000 esi: 00000400 edi: 00000000 ebp: 00000400 esp: f5ed1e9c ds: 0018 es: 0018 ss: 0018 Stack: c4aadbe8 c013f271 c4aadbe8 00000400 fe0a7000 f5ed1ec4 c019e335 00000400 00000000 f5ed1ec4 f54e0e94 c012c0eb f54e0e8c 00000000 c4aadbe8 c4aadbe8 c4aadbe8 f54e0df0 c4aadbe8 00000400 c013fc42 f54e0df0 c4aadbe8 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: c7 40 38 00 00 00 00 89 c2 8b 40 28 85 c0 75 f0 89 4a 28 b8 >>EIP; c013ef60 <===== Trace; c013f270 <__block_prepare_write+80/300> Trace; c019e334 Trace; c012c0ea <__add_to_page_cache+1a/70> Trace; c013fc42 Trace; c0176440 Trace; c01752cc Trace; c0176440 Trace; c0177cba Trace; c01486f0 Trace; c01487ae Trace; c010728a Code; c013ef60 00000000 <_EIP>: Code; c013ef60 <===== 0: c7 40 38 00 00 00 00 movl $0x0,0x38(%eax) <===== Code; c013ef66 7: 89 c2 mov %eax,%edx Code; c013ef68 9: 8b 40 28 mov 0x28(%eax),%eax Code; c013ef6c c: 85 c0 test %eax,%eax Code; c013ef6e e: 75 f0 jne 0 <_EIP> Code; c013ef70 10: 89 4a 28 mov %ecx,0x28(%edx) Code; c013ef72 13: b8 00 00 00 00 mov $0x0,%eax EFLAGS: 00010202 eax: 00000008 ebx: f6349e50 ecx: f6ee6c00 edx: 00000008 esi: f4b1e800 edi: 00000003 ebp: f6349e68 esp: f6349e04 ds: 0018 es: 0018 ss: 0018 Stack: c017651d 00000008 f6349e1c 00000003 00000003 00011a2a 00000000 c718fec0 000000f0 00000202 000000f0 c0132079 c718fec0 00000246 f6349e4c 00000000 f4f7859c 00000000 f4b1e740 f4f784b4 00000000 00000000 00000400 c013e179 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 42 14 85 c0 74 05 f0 ff 4a 14 c3 c7 44 24 04 a0 8b 26 c0 >>EIP; c013dea4 <__brelse+4/20> <===== Trace; c017651c Trace; c0132078 Trace; c013e178 Trace; c013e6d0 <__block_prepare_write+110/290> Trace; c013dd46 Trace; c013e904 <__block_commit_write+b4/e0> Trace; c013efa2 Trace; c0176410 Trace; c012eb90 Trace; c0176410 Trace; c012cdc0 Trace; c013be26 Trace; c013b8a0 Trace; c013bbce Trace; c0108cf6 Code; c013dea4 <__brelse+4/20> 00000000 <_EIP>: Code; c013dea4 <__brelse+4/20> <===== 0: 8b 42 14 mov 0x14(%edx),%eax <===== Code; c013dea6 <__brelse+6/20> 3: 85 c0 test %eax,%eax Code; c013dea8 <__brelse+8/20> 5: 74 05 je c <_EIP+0xc> c013deb0 <__brelse+10/20> Code; c013deaa <__brelse+a/20> 7: f0 ff 4a 14 lock decl 0x14(%edx) Code; c013deae <__brelse+e/20> b: c3 ret Code; c013deb0 <__brelse+10/20> c: c7 44 24 04 a0 8b 26 movl $0xc0268ba0,0x4(%esp,1) Code; c013deb6 <__brelse+16/20> 13: c0 -- Dave Hansen haveblue@us.ibm.com