JFFS2 deadlock with alloc_sem

[Roberts Nathan-mcg31137]

Has anyone seen this deadlock before? It seems to be a classic deadlock 
situation so I'm not sure if maybe I'm misinterpreting things or 
the use case (several postmark tests running in parallel on a
preemptible
kernel) is especially vulnerable. 

If the lock at NOTE2 is aquired followed by the lock at NOTE4, it seems 
like deadlock is inevitable. 

Kernel is 2.6.10 based. (although I've looked at 2.6.18 sources and it 
appears that the scenario is possible there as well.)

Kernel preemption is enabled. 

Flash is large page NAND (we've also got it to happen on small page NAND

but it's more difficult). 

It's not always the GC thread which is the other party.  We've also 
gotten other callers of garbage_collect_pass() to end up in the same 
situation.

Thread1
--
[<c023fd60>] (__schedule+0x0/0x5b0) from [<c024047c>]
(schedule+0xec/0x124)
[<c0240390>] (schedule+0x0/0x124) from [<c023f930>]
(__compat_down+0xe0/0x178)
 r4 = C0EA4000 
[<c023f850>] (__compat_down+0x0/0x178) from [<c023f7ec>]
(__compat_down_failed+0xc/0x20)
 r8 = C001462C  r7 = C2B7C2E8  r6 = C2B7C2E8  r5 = C0014600
 r4 = C2B7C30C 
[<c00d5b60>] (jffs2_reserve_space+0x0/0x268) from [<c00d80b4>]
(jffs2_write_inode_range+0x5c/0x468)
NOTE1: jffs2_reserve_space() releases and reaquires alloc_sem

[<c00d8058>] (jffs2_write_inode_range+0x0/0x468) from [<c00d30ac>]
(jffs2_commit_write+0x1b0/0x31c)
[<c00d2efc>] (jffs2_commit_write+0x0/0x31c) from [<c00638d8>]
(generic_file_buffered_write+0x3e4/0x64c)
[<c00634f4>] (generic_file_buffered_write+0x0/0x64c) from [<c00641c8>]
(__generic_file_aio_write_nolock+0x488/0x4b4)
NOTE2: generic_file_buffered_write() gets page_lock

[<c0063d40>] (__generic_file_aio_write_nolock+0x0/0x4b4) from
[<c0064274>] (__generic_file_write_nolock+0x80/0xac)
[<c00641f4>] (__generic_file_write_nolock+0x0/0xac) from [<c00643c4>]
(generic_file_write+0x58/0xdc)
 r9 = C0EA4000  r8 = C1CC3A00  r6 = 40030008  r5 = C1CC3A9C
 r4 = C1CC3A6C 
[<c006436c>] (generic_file_write+0x0/0xdc) from [<c007eeb4>]
(vfs_write+0xec/0x170)
[<c007edc8>] (vfs_write+0x0/0x170) from [<c007eff4>]
(sys_write+0x48/0x74)
 r8 = C0025154  r7 = 00000004  r6 = C26E7960  r5 = 00000000
 r4 = 0002D000 
[<c007efac>] (sys_write+0x0/0x74) from [<c00249a0>]
(ret_fast_syscall+0x0/0x34)
 r6 = 00000004  r5 = 0002D000  r4 = 0008A0FF 


Thread2
--
[<c023fd60>] (__schedule+0x0/0x5b0) from [<c024047c>]
(schedule+0xec/0x124)
[<c0240390>] (schedule+0x0/0x124) from [<c0241040>]
(io_schedule+0x2c/0x48)
 r4 = C02E01A8 
[<c0241014>] (io_schedule+0x0/0x48) from [<c0060bbc>]
(sync_page+0x40/0x48)
 r5 = 00000000  r4 = C34F7CF8 
[<c0060b7c>] (sync_page+0x0/0x48) from [<c024140c>]
(__wait_on_bit_lock+0x54/0x88)
[<c02413b8>] (__wait_on_bit_lock+0x0/0x88) from [<c00614a4>]
(__lock_page+0x88/0x98)
[<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

[<c00db1c0>] (jffs2_garbage_collect_pass+0x0/0x1c28) from [<c00de684>]
(jffs2_garbage_collect_thread+0x148/0x19c)
NOTE4: garbage_collect_pass() aquires alloc_sem

[<c00de53c>] (jffs2_garbage_collect_thread+0x0/0x19c) from [<c00444e8>]
(do_exit+0x0/0xd88)
 r7 = 00000000  r6 = 00000000  r5 = 00000000  r4 = 00000000