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,
-Eric
|