> BUG: unable to handle kernel paging request at virtual address 1000004b
On Fri, 2007-09-28 at 17:00 +0200, Norbert Preining wrote:
Thanks
Looks like kernel oops at 1753(173b+0x18):
0000173b <ext3_discard_reservation>:
ext3_discard_reservation():
173b: 57 push %edi
173c: 56 push %esi
173d: 89 c6 mov %eax,%esi
173f: 53 push %ebx
1740: 8b 58 b4 mov -0x4c(%eax),%ebx
1743: 8b 80 a4 00 00 00 mov 0xa4(%eax),%eax
1749: 85 db test %ebx,%ebx
174b: 8b 80 78 01 00 00 mov 0x178(%eax),%eax
1751: 74 30 je 1783
<ext3_discard_reservation+0x48>
1753: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
==========================> Kernel oops here, ebx=10000033, match bad
page location 1000004b(=10000033+0x18)
1757: 74 2a je 1783
<ext3_discard_reservation+0x48>
1759: 8d b8 00 03 00 00 lea 0x300(%eax),%edi
175f: 89 f8 mov %edi,%eax
1761: e8 fc ff ff ff call 1762
<ext3_discard_reservation+0x27>
1766: 83 7b 18 00 cmpl $0x0,0x18(%ebx)
176a: 74 0d je 1779
<ext3_discard_reservation+0x3e>
176c: 8b 86 a4 00 00 00 mov 0xa4(%esi),%eax
1772: 89 da mov %ebx,%edx
1774: e8 dc eb ff ff call 355 <rsv_window_remove>
1779: 89 f8 mov %edi,%eax
177b: 5b pop %ebx
177c: 5e pop %esi
177d: 5f pop %edi
177e: e9 fc ff ff ff jmp 177f
<ext3_discard_reservation+0x44>
1783: 5b pop %ebx
1784: 5e pop %esi
1785: 5f pop %edi
1786: c3 ret
And trying to matching to the code:
void ext3_discard_reservation(struct inode *inode)
{
struct ext3_inode_info *ei = EXT3_I(inode);
struct ext3_block_alloc_info *block_i = ei->i_block_alloc_info;
struct ext3_reserve_window_node *rsv;
spinlock_t *rsv_lock = &EXT3_SB(inode->i_sb)->s_rsv_window_lock;
if (!block_i)
return;
rsv = &block_i->rsv_window_node;
if (!rsv_is_empty(&rsv->rsv_window)) {
=================================> kernel oops here
spin_lock(rsv_lock);
if (!rsv_is_empty(&rsv->rsv_window))
rsv_window_remove(inode->i_sb, rsv);
spin_unlock(rsv_lock);
}
}
It seems ebx points to block_i(i_block_alloc_info), and that is bad
memory location, so that leads to bad paging request when try to get the
rsv_window structure.
But it confused me why the rsv_window offset is 0x18 to
i_block_alloc_info, it should be 0x14(20 bytes)...Are you running a
vanilla 2.6.23-rc6?
No clue how i_block_alloc_info pointing to a bad location for now.
ext3_alloc_inode() clearly init this field to NULL, and
ext3_clear_inode() clearly set this field to NULL. So during the
lifecycle of the inode, i_block_alloc_info should point to a valid
address or being NULL.
And the stack trace indicating the oops happened when pushing the inode
from the cache, so racing is not a issue there. Possible random memory
corruption?
Mingming
Mingming
-
