From: Linus Torvalds Date: Fri, 26 Jan 2007 20:47:06 +0000 (-0800) Subject: Resurrect 'try_to_free_buffers()' VM hackery X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=ecdfc9787fe527491baefc22dce8b2dbd5b2908d;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git 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 Acked-by: Jens Axboe Acked-by: Peter Zijlstra Cc: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/fs/buffer.c b/fs/buffer.c index 3b116078b4c3..460f1c43238e 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -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; diff --git a/mm/truncate.c b/mm/truncate.c index 6c79ca4a1ca7..3262740aa059 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -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)) {