In 46d2277c796f9f4937bfa668c40b2e3f43e93dd0, try_to_free_buffers was
changed to bail out if the page was dirty. That caused
truncate_complete_page to leak massive amounts of memory, because the
dirty bit was only cleared after the call to try_to_free_buffers. So the
call to cancel_dirty_page was moved up to have the dirty bit cleared
early in 3e67c0987d7567ad666641164a153dca9a43b11d.
The problem with that fix is, that the page can be redirtied after
cancel_dirty_page was called, eg. like this:
cancel_dirty_page() // PG_dirty cleared, decr. dirty pages
mark_buffer_dirty(); // PG_dirty set, incr. dirty pages
And then we end up with dirty pages being wrongly accounted.
In ecdfc9787fe527491baefc22dce8b2dbd5b2908d the changes to
try_to_free_buffers were reverted, so the original reason for the
massive memory leak is gone, so we can also revert the move of
the call to cancel_dirty_page from truncate_complete_page and get the
accounting right again.
Signed-off-by: Bj?rn Steinbrink <[email protected]>
Tested-by: Krzysztof Piotr Oledzki <[email protected]>
I'm not sure if it matters, but opposed to the final check in
__remove_from_page_cache, this one also cares about the task io
accounting, so maybe we want to use this instead, although it's not
quite the clean fix either.
diff --git a/mm/truncate.c b/mm/truncate.c
index cadc156..2974903 100644
@@ -98,11 +98,11 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
if (page->mapping != mapping)
- cancel_dirty_page(page, PAGE_CACHE_SIZE);
+ cancel_dirty_page(page, PAGE_CACHE_SIZE);