oops line 231 of latest readinode.c

[Artem B. Bityuckiy]

Is it possible to reproduce this? How if it is?

On Wed, 17 Nov 2004, Simon Haynes wrote:

> 
> I have been running some systems here for some time error free using a root 
> filesystem which is jffs2 on nand. One of them produced an oops today which 
> seemed to kill off kupdated. I had a look at the oops and it seems there is a 
> possible bug in jffs2_add_frag_to_fragtree.  
> 
> In my case all arguments appear to be valid kernel addresses. The call to 
> jffs2_lookup_node_frag returns a 0.  So the 'if (this)' takes the else route 
> and lastend is set to 0. We then execute the code in if (lastend <= 
> newfrag->ofs)' and then in the next if as newfrag->ofs contains -1. The oops 
> is produced by the line 'if(this->node)' because this is 0. I have checked 
> this against the latest CVS code and it would seem that this could still 
> happen.
> 
> I don't really know the flow of the code here but could I just put 
> 'if(this)' in front of 'if(this->node)' or is there some other more serious 
> problem here.
> 
> Here is the some of the ksymoops output
> 
> Oops: kernel access of bad area, sig: 11
> NIP: 8007D104 XER: 00000000 LR: 8007D0C8 SP: 802BFD80 REGS: 802bfcd0 TRAP: 
> 0800    Not tainted
> Using defaults from ksymoops -t elf32-powerpc -a powerpc:common
> MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = 802be000[6] 'kupdated' Last syscall: -1
> last math 00000000 last altivec 00000000
> GPR00: 000FFFFF 802BFD80 802BE000 00000000 FFFFFFFF 82C8FFB0 00400000 00000000
> GPR08: 82C8F000 000FFFFF 00000D90 00000000 82004228 1001F23C 00000000 00000000
> GPR16: 00000000 FFF8345A 00000000 00000000 00009032 80FFFF40 00000000 00000000
> GPR24: 00000000 80140000 00000000 828EAD14 00000000 82C8FFB0 00000000 83F48CC4
> Call backtrace:
> 83F48CC4 8007CFEC 8007D8D8 8007D6A8 80086B80 8004F4DC 8004F95C
> 800874F0 800823A4 800886EC 80086FB4 8003CBF0 8003BD44 8003C0EC
> 800061B0
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> >>NIP; 8007d104 <jffs2_add_frag_to_fragtree+68/3b0>   <=====
> 
> >>GPR1; 802bfd80 <_end+edcd8/4eaff58>
> >>GPR2; 802be000 <_end+ebf58/4eaff58>
> >>GPR5; 82c8ffb0 <_end+2abdf08/4eaff58>
> >>GPR8; 82c8f000 <_end+2abcf58/4eaff58>
> >>GPR12; 82004228 <_end+1e32180/4eaff58>
> >>GPR21; 80ffff40 <_end+e2de98/4eaff58>
> >>GPR25; 80140000 <crc32_table+3cc/1238>
> >>GPR27; 828ead14 <_end+2718c6c/4eaff58>
> >>GPR29; 82c8ffb0 <_end+2abdf08/4eaff58>
> >>GPR31; 83f48cc4 <_end+3d76c1c/4eaff58>
> 
> Trace; 83f48cc4 <_end+3d76c1c/4eaff58>
> Trace; 8007cfec <jffs2_add_full_dnode_to_inode+74/124>
> Trace; 8007d8d8 <jffs2_do_read_inode_internal+140/698>
> Trace; 8007d6a8 <jffs2_do_read_inode+198/1c4>
> Trace; 80086b80 <jffs2_read_inode+60/300>
> Trace; 8004f4dc <get_new_inode+d4/1bc>
> Trace; 8004f95c <iget4+130/144>
> Trace; 800874f0 <jffs2_gc_fetch_inode+b0/108>
> Trace; 800823a4 <jffs2_garbage_collect_pass+49c/564>
> Trace; 800886ec <jffs2_flush_wbuf_gc+cc/178>
> Trace; 80086
> 
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.