[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: JFFS2 stuck again.



On Wed, 11 Apr 2001, Vipin Malik wrote:

> Ok, this is what I got:
> 
> (gdb) list *0xc01774ad
> 0xc01774ad is in jffs2_garbage_collect_dirent (gc.c:360).
> 360             ret = jffs2_reserve_space_gc(c, sizeof(rd)+rd.nsize, &phys_ofs, &alloclen);
> 
> Looks like you were right!

Damn. :)

> One quick question though: How did you know that the call from
> ldconfig was for the same semaphore? There is no mention of
> any such call there? Did the "vfs_create(), open_namei() and filep_open()"
> clue you in as that (probably) has to go to the JFFS2 as those would work on
> the root fs (which is JFFS2)? TIA. 

Guess. vfs_create+0x90/0xc0 is almost certainly the call to 
dir->i_op->create() at about line 917 of fs/namei.c. jffs2_create() needs 
to allocate space too.

> >Assuming this confirms that it's the call to jffs2_reserve_space_gc() at
> >line 360 of gc.c, then someone who isn't on vacation needs to go through
> >the code looking for all instances of jffs2_reserve_space{_gc,} and
> >ensuring that jffs2_complete_reservation() is correctly called in all
> >circumstances where the reserve_space function succeeded.

Actually it's more likely to be something getting the jffs2_inode_info 
semaphore and the alloc_sem in the wrong order, causing deadlock.

-- 
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com