RE: JFFS2 stuck again.

[David Woodhouse <dwmw2@xxxxxxx.org>]

On Wed, 11 Apr 2001, David Woodhouse wrote:

> 
> OK, the lock ordering rules are as follows:
> 
> 1. If you need more than one jffs2_inode_info semaphore, you must 
> 	obtain the parent's lock before the child. jffs2_new_inode()
> 	returns it already locked now, to prevent that case from 
> 	being confusing (it was actually OK to lock that one because
> 	nobody else could have seen it anyway.)
> 	
> 2. You must never obtain a jffs2_inode_info semaphore while holding the 
> 	alloc_sem. This is the one which was killing us.

Right... I think the reason this doesn't work is because it is, to use a 
layman's term, utter bollocks. The whole point in putting a new semaphore 
in the jffs2_inode_info instead of just using the inode i_sem was because 
we needed to avoid precisely this deadlock with the GC.

We could possibly split the jffs2_reserve_space function into a loop of 
make_space, lock, and reserve_space, but I think that's ugly. 

A better option is to merge the gc_sem and the alloc_sem, and to make 
jffs2_reserve_space_gc not obtain that sem, which will be already locked 
anyway. And obviously stop the gc routines from releasing it twice too - 
in the calls to jffs2_complete_reservation. 

I'm not about to implement this. I'm on vacation. Volunteers welcome.

-- 
dwmw2



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