Another JFFS2 deadlock, kernel 3.4.11

[Thomas.Betker at rohde-schwarz.com]

Hello wangzaiwei:

> > Deng Chao has created a patch which a) removes the deadlock I wanted 
to 
> > get rid of originally, without b) introducing the new deadlocks; see 
> > http://lists.infradead.org/pipermail/linux-mtd/2013-August/048352.html
. 
> > However, his patch modifies mm/filemap.c, and we were hoping to find a 

> > more light-weight solution -- which never came to be.
> 
> > I do use his patch here around, though, and so far, it has worked 
fine. I 
> > will try to run your test scripts on one of our devices, and see if it 

> > holds up.

I have run your scripts on my device (with Deng Chao's patch) for three 
hours. None of the scripts got into state 'D', and the system is still 
alive (2 CPUs, so if a deadlock had occurred, the system would have 
stopped dead).

> Though I didn't know about that Deng Chao and Ming Liu had reported the 
issue,
> I have had the same patch thinking.
> 
> Yes,these deadlock issues which we have found always occured between
> gc thread(may 
> actived by sync system call) and other user tasks
> 
> gc thread just like :
> > for [sync_supers]
> > jffs2_garbage_collect_live
> >     mutex_lock(&f->sem)                         (A)
> >     jffs2_garbage_collect_dnode
> >         jffs2_gc_fetch_page
> >             read_cache_page_async
> >                 do_read_cache_page
> >                     lock_page(page)             (B)
> 
> 
> if we change lock_page(page) above to lock_page_try(page),deadlock 
> will go away.
> 
> But i worry about this workaround. jffs2_garbage_collect_live action
> will changed.
> and jffs2_garbage_collect_live is called not only by gc thread.
> Is it ok to return an error rather than blocking . 
> Can syscall 'sync' still reach its goal ?

I think that Deng Chao has discussed this in his patch. We have been using 
the patch for almost two years now, and I didn't see any bad effects yet.

Best regards,
Thomas Betker