[BUG report]xfs_btree_make_block_unfull generated an OOPS
hank peng
pengxihan at gmail.com
Tue Dec 8 21:18:49 CST 2009
2009/12/9 Eric Sandeen <sandeen at sandeen.net>:
> hank peng wrote:
>> Hi, all:
>> I think it is a BUG, so I report it here.
>> root at 1234dahua:~# uname -a
>> Linux 1234dahua 2.6.31.6 #14 Tue Dec 8 16:48:40 CST 2009 ppc unknown
>>
>> Unable to handle kernel paging request for data at address 0x00000000
>> Faulting instruction address: 0xc019ea28
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> MPC85xx CDS
>> Modules linked in:
>> NIP: c019ea28 LR: c019ea00 CTR: 00000000
>> REGS: e233baf0 TRAP: 0300 Not tainted (2.6.31.6)
>> MSR: 00029000 <EE,ME,CE> CR: 22008484 XER: 00000000
>> DEAR: 00000000, ESR: 00800000
>> TASK = e8add2c0[21249] 'SS_Server' THREAD: e233a000
>> GPR00: 000001a4 e233bba0 e8add2c0 00000000 00000000 00000000 00000001 00000000
>> GPR08: c0e22478 e20137b8 c0e2247c 000001a4 22008422 1016d410 3fff5400 100a0000
>> GPR16: 100ce108 00000000 006398bb e20137b8 c019c58c 00029000 e233bc5c c0186bd0
>> GPR24: c019c568 00000000 22008424 e233bc08 00000000 e233bc58 00000000 e20137b8
>> NIP [c019ea28] xfs_btree_make_block_unfull+0xc4/0x1b0
>
> huh, I don't think I've ever seen an oops here, nor has kerneloops.org.
>
> I wonder how you managed this ... :)
>
>> LR [c019ea00] xfs_btree_make_block_unfull+0x9c/0x1b0
>> Call Trace:
>> [e233bba0] [c019ea00] xfs_btree_make_block_unfull+0x9c/0x1b0 (unreliable)
>> [e233bbe0] [c019ee88] xfs_btree_insrec+0x374/0x4b0
>> [e233bc50] [c019f040] xfs_btree_insert+0x7c/0x1c0
>> [e233bcb0] [c0185ad0] xfs_free_ag_extent+0x34c/0x810
>
> so this is freeing blocks and adding them to the freespace btrees;
> it needs to move entries out of a block to make room for the new one.
> Not a terribly unusual operation, I think.
>
>> [e233bd20] [c0186668] xfs_free_extent+0xdc/0x104
>> [e233bdb0] [c018f350] xfs_bmap_finish+0x154/0x1a0
>> [e233bde0] [c01b5e34] xfs_itruncate_finish+0x254/0x3b8
>> [e233be60] [c01d033c] xfs_free_eofblocks+0x254/0x29c
>> [e233bee0] [c01d9ba8] xfs_file_release+0x14/0x28
>> [e233bef0] [c009574c] __fput+0xe8/0x1dc
>> [e233bf10] [c0092048] filp_close+0x70/0xb0
>> [e233bf30] [c009211c] sys_close+0x94/0xc0
>> [e233bf40] [c000f784] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7fa5eb78 4bffdf59 7c7c1b79 40a2ffd4 801d0000 2f800000 419e0064 57c9103a
>> 7f83e378 7d29fa14 80090050 90170000 <90190000> 80010044 bae1001c 38210040
>> ---[ end trace 069fbb7d042289d2 ]---
>>
>> According to the above call trace, I checked the source code and found
>> that it may be invoked by xfs_btree_make_block_unfull function in
>> fs/xfs/xfs_btree.c:
>>
>> 2641
>> 2642 if (*stat) {
>> 2643 *oindex = *index = cur->bc_ptrs[level];
>> 2644 return 0;
>> 2645 }
>>
>> here, oindex is NULL so OOPs occured. I am not a xfs hacker, I hope
>> someone can help me fix this BUG, if you need more information, let me
>> know.
>
> Is the above from gdb? You're quite certain that this is the case,
> or is this a guess?
>
> It seems a little unlikely because in the calling function:
>
> int optr; /* old key/record index */
> int ptr; /* key/record index */
>
> // .... code code code ...
>
> if (numrecs == cur->bc_ops->get_maxrecs(cur, level)) {
> error = xfs_btree_make_block_unfull(cur, level, numrecs,
> &optr, &ptr, &nptr, &ncur, &nrec, stat);
>
> We're just sending in the addresses of these local variables;
> I don't see how these pointers could be NULL.
>
Thanks for your replay.
I made this conclusion from assembly code, correct me if I am wrong.
#powerpc-linux-gnuspe-objdump vmlinux | less
<snip>
c019e964 <xfs_btree_make_block_unfull>:
c019e964: 94 21 ff c0 stwu r1,-64(r1)
c019e968: 7c 08 02 a6 mflr r0
c019e96c: be e1 00 1c stmw r23,28(r1)
c019e970: 7c 7f 1b 78 mr r31,r3
c019e974: 90 01 00 44 stw r0,68(r1)
c019e978: 7c bc 2b 78 mr r28,r5
c019e97c: 7c d9 33 78 mr r25,r6 <I think
here r6 store value of oindex >
c019e980: 83 a1 00 48 lwz r29,72(r1)
c019e984: 7c f7 3b 78 mr r23,r7
c019e988: 80 03 00 0c lwz r0,12(r3)
c019e98c: 7d 1b 43 78 mr r27,r8
c019e990: 7d 3a 4b 78 mr r26,r9
c019e994: 7d 58 53 78 mr r24,r10
c019e998: 7c 9e 23 78 mr r30,r4
c019e99c: 70 0b 00 02 andi. r11,r0,2
c019e9a0: 41 82 00 14 beq- c019e9b4
<xfs_btree_make_block_unfull+0x50>
c019e9a4: 89 23 00 78 lbz r9,120(r3)
c019e9a8: 39 29 ff ff addi r9,r9,-1
c019e9ac: 7f 84 48 00 cmpw cr7,r4,r9
c019e9b0: 41 9e 00 90 beq- cr7,c019ea40
<xfs_btree_make_block_unfull+0xdc>
c019e9b4: 7f e3 fb 78 mr r3,r31
c019e9b8: 7f c4 f3 78 mr r4,r30
c019e9bc: 7f a5 eb 78 mr r5,r29
c019e9c0: 4b ff db 39 bl c019c4f8 <xfs_btree_rshift>
c019e9c4: 7c 7c 1b 79 mr. r28,r3
c019e9c8: 40 82 00 10 bne- c019e9d8
<xfs_btree_make_block_unfull+0x74>
c019e9cc: 80 1d 00 00 lwz r0,0(r29)
c019e9d0: 2f 80 00 00 cmpwi cr7,r0,0
c019e9d4: 41 9e 00 1c beq- cr7,c019e9f0
<xfs_btree_make_block_unfull+0x8c>
c019e9d8: 80 01 00 44 lwz r0,68(r1)
c019e9dc: 7f 83 e3 78 mr r3,r28
c019e9e0: ba e1 00 1c lmw r23,28(r1)
c019e9e4: 38 21 00 40 addi r1,r1,64
c019e9e8: 7c 08 03 a6 mtlr r0
c019e9ec: 4e 80 00 20 blr
c019e9f0: 7f e3 fb 78 mr r3,r31
c019e9f4: 7f c4 f3 78 mr r4,r30
c019e9f8: 7f a5 eb 78 mr r5,r29
c019e9fc: 4b ff df 59 bl c019c954 <xfs_btree_lshift>
c019ea00: 7c 7c 1b 79 mr. r28,r3
c019ea04: 40 a2 ff d4 bne- c019e9d8
<xfs_btree_make_block_unfull+0x74>
c019ea08: 80 1d 00 00 lwz r0,0(r29)
c019ea0c: 2f 80 00 00 cmpwi cr7,r0,0
c019ea10: 41 9e 00 64 beq- cr7,c019ea74
<xfs_btree_make_block_unfull+0x110>
c019ea14: 57 c9 10 3a rlwinm r9,r30,2,0,29
c019ea18: 7f 83 e3 78 mr r3,r28
c019ea1c: 7d 29 fa 14 add r9,r9,r31
c019ea20: 80 09 00 50 lwz r0,80(r9)
c019ea24: 90 17 00 00 stw r0,0(r23)
c019ea28: 90 19 00 00 stw r0,0(r25) <OOPs
occured here>
c019ea2c: 80 01 00 44 lwz r0,68(r1)
c019ea30: ba e1 00 1c lmw r23,28(r1)
c019ea34: 38 21 00 40 addi r1,r1,64
c019ea38: 7c 08 03 a6 mtlr r0
> Thanks,
> -Eric
>
--
The simplest is not all best but the best is surely the simplest!
More information about the xfs
mailing list