fs: introduce some page/buffer invariants

It is a bug to set a page dirty if it is not uptodate unless it has
buffers.  If the page has buffers, then the page may be dirty (some buffers
dirty) but not uptodate (some buffers not uptodate).  The exception to this
rule is if the set_page_dirty caller is racing with truncate or invalidate.

A buffer can not be set dirty if it is not uptodate.

If either of these situations occurs, it indicates there could be some data
loss problem.  Some of these warnings could be a harmless one where the
page or buffer is set uptodate immediately after it is dirtied, however we
should fix those up, and enforce this ordering.

Bring the order of operations for truncate into line with those of
invalidate.  This will prevent a page from being able to go !uptodate while
we're holding the tree_lock, which is probably a good thing anyway.

Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

1 files changed, 1 insertions, 0 deletions

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index ea9da3bed3e9..886ea0d5a136 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -824,6 +824,7 @@ int __set_page_dirty_nobuffers(struct page *page)
                 mapping2 = page_mapping(page);
                 if (mapping2) { /* Race with truncate? */
                         BUG_ON(mapping2 != mapping);
+                        WARN_ON_ONCE(!PagePrivate(page) && !PageUptodate(page));
                         if (mapping_cap_account_dirty(mapping)) {
                                 __inc_zone_page_state(page, NR_FILE_DIRTY);
                                 task_io_account_write(PAGE_CACHE_SIZE);