From: Dave Hansen <haveblue@us.ibm.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org
Subject: OOPS caused by ext2 changes
Date: Mon, 15 Apr 2002 18:16:35 -0700 [thread overview]
Message-ID: <3CBB7B73.8090104@us.ibm.com> (raw)
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:[<c013ef60>] 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: [<c013f271>] [<c019e335>] [<c012c0eb>] [<c013fc42>]
[<c0176440>]
[<c01752cc>] [<c0176440>] [<c0177cba>] [<c01486f0>] [<c01487ae>]
[<c010728b>]
Code: c7 40 38 00 00 00 00 89 c2 8b 40 28 85 c0 75 f0 89 4a 28 b8
>>EIP; c013ef60 <create_empty_buffers+30/60> <=====
Trace; c013f270 <__block_prepare_write+80/300>
Trace; c019e334 <radix_tree_insert+14/30>
Trace; c012c0ea <__add_to_page_cache+1a/70>
Trace; c013fc42 <block_prepare_write+22/70>
Trace; c0176440 <ext2_get_block+0/3c0>
Trace; c01752cc <ext2_make_empty+3c/110>
Trace; c0176440 <ext2_get_block+0/3c0>
Trace; c0177cba <ext2_mkdir+8a/100>
Trace; c01486f0 <vfs_mkdir+60/90>
Trace; c01487ae <sys_mkdir+8e/d0>
Trace; c010728a <syscall_call+6/a>
Code; c013ef60 <create_empty_buffers+30/60>
00000000 <_EIP>:
Code; c013ef60 <create_empty_buffers+30/60> <=====
0: c7 40 38 00 00 00 00 movl $0x0,0x38(%eax) <=====
Code; c013ef66 <create_empty_buffers+36/60>
7: 89 c2 mov %eax,%edx
Code; c013ef68 <create_empty_buffers+38/60>
9: 8b 40 28 mov 0x28(%eax),%eax
Code; c013ef6c <create_empty_buffers+3c/60>
c: 85 c0 test %eax,%eax
Code; c013ef6e <create_empty_buffers+3e/60>
e: 75 f0 jne 0 <_EIP>
Code; c013ef70 <create_empty_buffers+40/60>
10: 89 4a 28 mov %ecx,0x28(%edx)
Code; c013ef72 <create_empty_buffers+42/60>
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: [<c017651d>] [<c0132079>] [<c013e179>] [<c013e6d1>]
[<c013dd46>]
[<c013e904>] [<c013efa2>] [<c0176410>] [<c012eb90>] [<c0176410>]
[<c012cdc0>]
[<c013be26>] [<c013b8a0>] [<c013bbce>] [<c0108cf7>]
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 <ext2_get_block+10c/470>
Trace; c0132078 <kmem_cache_alloc+78/120>
Trace; c013e178 <create_buffers+68/100>
Trace; c013e6d0 <__block_prepare_write+110/290>
Trace; c013dd46 <balance_dirty+6/50>
Trace; c013e904 <__block_commit_write+b4/e0>
Trace; c013efa2 <block_prepare_write+22/80>
Trace; c0176410 <ext2_get_block+0/470>
Trace; c012eb90 <generic_file_write+500/750>
Trace; c0176410 <ext2_get_block+0/470>
Trace; c012cdc0 <file_read_actor+0/100>
Trace; c013be26 <sys_write+96/d0>
Trace; c013b8a0 <generic_file_llseek+0/d0>
Trace; c013bbce <sys_lseek+6e/80>
Trace; c0108cf6 <syscall_call+6/a>
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
next reply other threads:[~2002-04-16 1:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-16 1:16 Dave Hansen [this message]
2002-04-16 3:27 ` OOPS caused by ext2 changes Andrew Morton
2002-04-16 5:31 ` David C. Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CBB7B73.8090104@us.ibm.com \
--to=haveblue@us.ibm.com \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.