summaryrefslogtreecommitdiffstats
path: root/COPYING
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@woody.linux-foundation.org>2007-01-26 21:47:06 +0100
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-01-26 21:47:06 +0100
commitecdfc9787fe527491baefc22dce8b2dbd5b2908d (patch)
tree31e7ddac0339498095c40444f81c0b03751434ae /COPYING
parent[PATCH] x86_64: fix put_user for 64-bit constant (diff)
downloadlinux-ecdfc9787fe527491baefc22dce8b2dbd5b2908d.tar.xz
linux-ecdfc9787fe527491baefc22dce8b2dbd5b2908d.zip
Resurrect 'try_to_free_buffers()' VM hackery
It's not pretty, but it appears that ext3 with data=journal will clean pages without ever actually telling the VM that they are clean. This, in turn, will result in the VM (and balance_dirty_pages() in particular) to never realize that the pages got cleaned, and wait forever for an event that already happened. Technically, this seems to be a problem with ext3 itself, but it used to be hidden by 'try_to_free_buffers()' noticing this situation on its own, and just working around the filesystem problem. This commit re-instates that hack, in order to avoid a regression for the 2.6.20 release. This fixes bugzilla 7844: http://bugzilla.kernel.org/show_bug.cgi?id=7844 Peter Zijlstra points out that we should probably retain the debugging code that this removes from cancel_dirty_page(), and I agree, but for the imminent release we might as well just silence the warning too (since it's not a new bug: anything that triggers that warning has been around forever). Acked-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Jens Axboe <jens.axboe@oracle.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions