[00/11] fix ext4 deadlock on 2.6.27.y

[Jayson R. King]

Greetings,

Using the kernel 2.6.27.45 with an ext4 filesystem, the same deadlock as
was reported earlier in kernel bugzilla #12579 can occur. Simply running
"dbench 500" on an ext4 filesystem can cause the deadlock in one to two
minutes.

In later stable kernels, the deadlock was fixed by commit 2acf2c26
("ext4: Implement range_cyclic in ext4_da_writepages instead of
write_cache_pages"). I can confirm that the same commit fixes the
deadlock on 2.6.27.y. However, as the code in ext4_da_writepages is
different in 2.6.27.y than in later kernels, it was necessary to add
some other mainline patches before 2acf2c26.

Alltogether, I've added 11 mainline patches including 2acf2c26 to my
local 2.6.27.y kernel, and confirmed that the deadlock is fixed only
when the patch 2acf2c26 is applied.

The 11 patches are:

Aneesh Kumar K.V (10):
      ext4: invalidate pages if delalloc block allocation fails.
      ext4: Make sure all the block allocation paths reserve blocks
      ext4: Add percpu dirty block accounting.
      ext4: Retry block reservation
      ext4: Retry block allocation if we have free blocks left
      ext4: Use tag dirty lookup during mpage_da_submit_io
      vfs: Remove the range_cont writeback mode.
      vfs: Add no_nrwrite_index_update writeback control flag
      ext4: Fix file fragmentation during large file write.
      ext4: Implement range_cyclic in ext4_da_writepages instead of write_cache_pages

Mingming Cao (1):
      percpu counter: clean up percpu_counter_sum_and_set()

All will be posted in a reply to this message, in the order that they apply.

I think these patches should be committed to stable 2.6.27.y.

Most of these patches applied cleanly to 2.6.27.45 with no changes other
than some context lines, but two of the patches needed some very slight
modifications. I'll note the changes that I made to them above my
signed-off line for each.

Jayson

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/