Commit ecdfc978 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

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: default avatarRandy Dunlap <rdunlap@xenotime.net>
Acked-by: default avatarJens Axboe <jens.axboe@oracle.com>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 5ad0d383

fs/buffer.c

+14 −1
Original line number Diff line number Diff line
@@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *page) 
	int ret = 0;



	BUG_ON(!PageLocked(page));

	if (PageDirty(page) || PageWriteback(page))

	if (PageWriteback(page))

		return 0;



	if (mapping == NULL) {		/* can this still happen? */
@@ -2845,6 +2845,19 @@ int try_to_free_buffers(struct page *page) 
	spin_lock(&mapping->private_lock);

	ret = drop_buffers(page, &buffers_to_free);

	spin_unlock(&mapping->private_lock);



	/*

	 * If the filesystem writes its buffers by hand (eg ext3)

	 * then we can have clean buffers against a dirty page.  We

	 * clean the page here; otherwise the VM will never notice

	 * that the filesystem did any IO at all.

	 *

	 * Also, during truncate, discard_buffer will have marked all

	 * the page's buffers clean.  We discover that here and clean

	 * the page also.

	 */

	if (ret)

		cancel_dirty_page(page, PAGE_CACHE_SIZE);

out:

	if (buffers_to_free) {

		struct buffer_head *bh = buffers_to_free;

mm/truncate.c

+14 −7
Original line number Diff line number Diff line
@@ -51,15 +51,22 @@ static inline void truncate_partial_page(struct page *page, unsigned partial) 
		do_invalidatepage(page, partial);

}



/*

 * This cancels just the dirty bit on the kernel page itself, it

 * does NOT actually remove dirty bits on any mmap's that may be

 * around. It also leaves the page tagged dirty, so any sync

 * activity will still find it on the dirty lists, and in particular,

 * clear_page_dirty_for_io() will still look at the dirty bits in

 * the VM.

 *

 * Doing this should *normally* only ever be done when a page

 * is truncated, and is not actually mapped anywhere at all. However,

 * fs/buffer.c does this when it notices that somebody has cleaned

 * out all the buffers on a page without actually doing it through

 * the VM. Can you say "ext3 is horribly ugly"? Tought you could.

 */

void cancel_dirty_page(struct page *page, unsigned int account_size)

{

	/* If we're cancelling the page, it had better not be mapped any more */

	if (page_mapped(page)) {

		static unsigned int warncount;



		WARN_ON(++warncount < 5);

	}

		

	if (TestClearPageDirty(page)) {

		struct address_space *mapping = page->mapping;

		if (mapping && mapping_cap_account_dirty(mapping)) {

CRA Git | Maintained and supported by SUSTech CRA and CCSE