xfs
[Top] [All Lists]

Re: [BUG report]xfs_btree_make_block_unfull generated an OOPS

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [BUG report]xfs_btree_make_block_unfull generated an OOPS
From: hank peng <pengxihan@xxxxxxxxx>
Date: Wed, 9 Dec 2009 11:18:49 +0800
Cc: linux-xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QaVL3KZGD0kON0lgaS4E1nm6Jz/Jiq7WrIReHspIDMA=; b=bdcscpsu62/oKuUGLcB4XBZCEe5d5NiWvPLYFX8o3eF6e25YJUhxIQXdI1J6yGqcdf HFyyjvvVa4hT6dB5CLAYHi85hVUnLEF1Zdko7mVebySBvGoiwIfV/aw8K+rmHjcnGnpf mY/dupWMwUCQ86uAQ+DpIf0Lo/FjLJ96ePmQ0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=u54m0JtLv5RLZ21ayrSsBY4onLwHjWmfcufHmNU4ZakiXdNhrcbqD2KpPkLZ7Tc6iE Q7R3i+S664cUwHHoCOle09IO+PMRm4X+6fhW+jCMiwCceinj9v7ONcoRGlxMuNjoecSg R8pNCAxQO7lgZEs0V/pckoTcJEV7a01Rb/y9k=
In-reply-to: <4B1F1211.90607@xxxxxxxxxxx>
References: <389deec70912081758x5af751b8pe3189aee6cb98e97@xxxxxxxxxxxxxx> <4B1F1211.90607@xxxxxxxxxxx>
2009/12/9 Eric Sandeen <sandeen@xxxxxxxxxxx>:
> hank peng wrote:
>> Hi, all:
>> I think it is a BUG, so I report it here.
>> root@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!

<Prev in Thread] Current Thread [Next in Thread>