[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: JFFS2 stuck again.
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.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org