Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecdfc9787fe527491baefc22dce8b2dbd5b2908d
Commit:     ecdfc9787fe527491baefc22dce8b2dbd5b2908d
Parent:     5ad0d383ddbf0d2fce43b8aac267a6c299fd2dff
Author:     Linus Torvalds <[EMAIL PROTECTED]>
AuthorDate: Fri Jan 26 12:47:06 2007 -0800
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Fri Jan 26 12:47:06 2007 -0800

    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 <[EMAIL PROTECTED]>
    Acked-by: Jens Axboe <[EMAIL PROTECTED]>
    Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
    Cc: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 fs/buffer.c   |   15 ++++++++++++++-
 mm/truncate.c |   21 ++++++++++++++-------
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 3b11607..460f1c4 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 6c79ca4..3262740 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)) {
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to