Another JFFS2 deadlock, kernel 3.4.11

[Thomas.Betker at rohde-schwarz.com]

Hello Deng:

>   My patch makes jffs2_garbage_collect_pass return 0 NOT error when 
> it can not get page lock. This means "try again".
>   No matter where jffs2_garbage_collect_pass is called, it will 
> always loop until it gets its goal.
>   However wangzaiwei's doubt is somehow reasonable. 
> jffs2_garbage_collect_pass is not only called by gc thread but also 
> by jffs2_reserve_space, this will introduce a living lock in a rare 
situation.
>   Consider this:
>   The disk is almost full, this means jffs2_reserve_space may call 
> jffs2_garbage_collect_pass to get free space when performing write 
operation.
>   Then Thread A has acquired the page lock when it is now writing, 
> and its priority is low.
>   Thread B is a rt thread, and its priority is higher than A, is 
> also writing. If B preempts A when A is holding the page lock, and 
> in the same time B calls jffs2_reserve_space->jffs2_collect_pass to 
> acquire the page lock, living lock occurs: B will always loop to 
> wait A to release the page lock which is preemptted by B itself.
> 
>   To solve this, I make jffs2_reserve_space to sleep a while when it
> finds jffs2_garbage_collect_pass cannot fetch the page lock.
> 
>   Still，I agree with Thomas that my patch is too heavy. It will be 
> much better if we find way to just modify jffs2_garbage_collect_pass
> to avoid the original deadlock.
>   But I think the fix is too tricky to me, I have not got any idea yet.

I would still think it's a goood idea if you sent your current patch to 
linux-mtd and linux-mm. At the moment, it's the only solution we got, and 
perhaps somebody on linux-mm will find a better way. And your (old) patch 
has been running happily on our devices for almost two years now, so I can 
provide a Tested-by:.

@wangzaiwei: Your test scripts have actually run for 24 hours on my device 
without any problems (I had to stop it this morning).

Best regards,
Thomas Betker