JFFS2 deadlock with alloc_sem

[David Woodhouse]

On Mon, 2007-04-30 at 15:41 -0400, Roberts Nathan-mcg31137 wrote:
> [<c006141c>] (__lock_page+0x0/0x98) from [<c006301c>] (read_cache_page+0x21c/0x324)
>  r5 = 00000000  r4 = C0336FE0 
> [<c0062e00>] (read_cache_page+0x0/0x324) from [<c00df8f8>] (jffs2_gc_fetch_page+0x2c/0x64)
> [<c00df8cc>] (jffs2_gc_fetch_page+0x0/0x64) from [<c00dc664>] (jffs2_garbage_collect_pass+0x14a4/0x1c28)
> NOTE3: jffs2_gc_fetch_page() attempts to get page_lock

This bit confuses me.

In jffs2_commit_write() we deliberately mark the page up to date, in
order to avoid this situation -- if the page is up to date,
read_cache_page() won't attempt to lock it.

(Note that we only set it up to date manually there if we're writing the
whole page. If we're writing less than a whole page, then
jffs2_prepare_write() will have read it and marked it up to date anyway.

So it's possible that read_cache_page() will try to lock a page when
called from jffs2_gc_fetch_page() -- but it _shouldn't_ be a page which
is already locked for writing. It should be a _different_ page.

Can you add a WARN_ON(!PageUptodate(pg)) into jffs2_commit_write(), just
before the call to jffs2_write_inode_range(). And/or otherwise try to
check which page each one is locking?

-- 
dwmw2