From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: torvalds@linux-foundation.org, gregkh@suse.de
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
linux-mm@kvack.org
Subject: [S390] page_mkclean data corruption.
Date: Wed, 04 Apr 2007 18:37:04 +0200 [thread overview]
Message-ID: <1175704624.31111.3.camel@localhost> (raw)
Linus, Greg,
the attached patch fixes a data corruption problem that has been
introduced with the page_mkclean/clear_page_dirty_for_io change
(the "Yes, Virginia, this is indeed insane." problem :-/)
In essence the fact that clear_page_dirty_for_io is called for
not-uptodate pages causes data corruption for architectures that use
page_test_and_clear_dirty (which is s390 only).
This should go into 2.6.21-rc and 2.6.20-stable.
Please pull message from git390 will follow.
blue skies,
Martin.
--
Subject: [S390] page_mkclean data corruption.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
The git commit c2fda5fed81eea077363b285b66eafce20dfd45a which
added the page_test_and_clear_dirty call to page_mkclean and the
git commit 7658cc289288b8ae7dd2c2224549a048431222b3 which fixes
the "nasty and subtle race in shared mmap'ed page writeback"
problem in clear_page_dirty_for_io cause data corruption on s390.
The effect of the two changes is that for every call to
clear_page_dirty_for_io a page_test_and_clear_dirty is done. If
the per page dirty bit is set set_page_dirty is called. Strangly
clear_page_dirty_for_io is called for not-uptodate pages, e.g.
over this call-chain:
[<000000000007c0f2>] clear_page_dirty_for_io+0x12a/0x130
[<000000000007c494>] generic_writepages+0x258/0x3e0
[<000000000007c692>] do_writepages+0x76/0x7c
[<00000000000c7a26>] __writeback_single_inode+0xba/0x3e4
[<00000000000c831a>] sync_sb_inodes+0x23e/0x398
[<00000000000c8802>] writeback_inodes+0x12e/0x140
[<000000000007b9ee>] wb_kupdate+0xd2/0x178
[<000000000007cca2>] pdflush+0x162/0x23c
The bad news now is that page_test_and_clear_dirty might claim
that a not-uptodate page is dirty since SetPageUptodate which
resets the per page dirty bit has not yet been called. The page
writeback that follows clobbers the data on disk.
The simplest solution to this problem is to move the call to
page_test_and_clear_dirty under the "if (page_mapped(page))".
If a file backed page is mapped it is uptodate.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
mm/rmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/mm/rmap.c linux-2.6-patched/mm/rmap.c
--- linux-2.6/mm/rmap.c 2007-04-04 14:23:22.000000000 +0200
+++ linux-2.6-patched/mm/rmap.c 2007-04-04 14:23:35.000000000 +0200
@@ -498,9 +498,9 @@ int page_mkclean(struct page *page)
struct address_space *mapping = page_mapping(page);
if (mapping)
ret = page_mkclean_file(mapping, page);
+ if (page_test_and_clear_dirty(page))
+ ret = 1;
}
- if (page_test_and_clear_dirty(page))
- ret = 1;
return ret;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2007-04-04 16:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 16:37 Martin Schwidefsky [this message]
2007-04-04 17:10 ` Linus Torvalds
2007-04-04 17:35 ` Martin Schwidefsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1175704624.31111.3.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox