From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Chuck Ebbert <cebbert@redhat.com>,
Domenico Andreoli <cavokz@gmail.com>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jan Kara <jack@suse.cz>, Nick Piggin <npiggin@suse.de>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [patch 02/36] rd: fix data corruption on memory pressure Future of Linux 2.6.22.y series
Date: Wed, 12 Dec 2007 22:33:53 -0800 [thread overview]
Message-ID: <20071213063353.GC25301@kroah.com> (raw)
In-Reply-To: <20071213063308.GA25301@kroah.com>
[-- Attachment #1: rd-fix-data-corruption-on-memory-pressure.patch --]
[-- Type: text/plain, Size: 2552 bytes --]
2.6.22-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Christian Borntraeger <borntraeger@de.ibm.com>
commit 5d0360ee96a5ef953dbea45873c2a8c87e77d59b upstream.
We have seen ramdisk based install systems, where some pages of mapped
libraries and programs were suddendly zeroed under memory pressure. This
should not happen, as the ramdisk avoids freeing its pages by keeping
them dirty all the time.
It turns out that there is a case, where the VM makes a ramdisk page
clean, without telling the ramdisk driver. On memory pressure
shrink_zone runs and it starts to run shrink_active_list. There is a
check for buffer_heads_over_limit, and if true, pagevec_strip is called.
pagevec_strip calls try_to_release_page. If the mapping has no
releasepage callback, try_to_free_buffers is called. try_to_free_buffers
has now a special logic for some file systems to make a dirty page
clean, if all buffers are clean. Thats what happened in our test case.
The simplest solution is to provide a noop-releasepage callback for the
ramdisk driver. This avoids try_to_free_buffers for ramdisk pages.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Nick Piggin <npiggin@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/block/rd.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/drivers/block/rd.c
+++ b/drivers/block/rd.c
@@ -189,6 +189,18 @@ static int ramdisk_set_page_dirty(struct
return 0;
}
+/*
+ * releasepage is called by pagevec_strip/try_to_release_page if
+ * buffers_heads_over_limit is true. Without a releasepage function
+ * try_to_free_buffers is called instead. That can unset the dirty
+ * bit of our ram disk pages, which will be eventually freed, even
+ * if the page is still in use.
+ */
+static int ramdisk_releasepage(struct page *page, gfp_t dummy)
+{
+ return 0;
+}
+
static const struct address_space_operations ramdisk_aops = {
.readpage = ramdisk_readpage,
.prepare_write = ramdisk_prepare_write,
@@ -196,6 +208,7 @@ static const struct address_space_operat
.writepage = ramdisk_writepage,
.set_page_dirty = ramdisk_set_page_dirty,
.writepages = ramdisk_writepages,
+ .releasepage = ramdisk_releasepage,
};
static int rd_blkdev_pagecache_IO(int rw, struct bio_vec *vec, sector_t sector,
--
next prev parent reply other threads:[~2007-12-13 6:37 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071213062511.265908583@mini.kroah.org>
2007-12-13 6:33 ` [patch 00/36] 2.6.22-stable review Greg KH
2007-12-13 6:33 ` [patch 01/36] atl1: disable broken 64-bit DMA Greg KH
2007-12-13 6:33 ` Greg KH [this message]
2007-12-13 6:34 ` [patch 03/36] wait_task_stopped(): pass correct exit_code to wait_noreap_copyout() Greg KH
2007-12-13 6:34 ` [patch 04/36] USB: make the microtek driver and HAL cooperate Greg KH
2007-12-13 6:34 ` [patch 05/36] USB: fix up EHCI startup synchronization Greg KH
2007-12-13 6:34 ` [patch 06/36] tmpfs: restore missing clear_highpage Greg KH
2007-12-13 6:34 ` [patch 07/36] nf_nat: fix memset error Greg KH
2007-12-13 6:34 ` [patch 08/36] libcrc32c: keep intermediate crc state in cpu order Greg KH
2007-12-13 6:34 ` [patch 09/36] isdn: avoid copying overly-long strings Greg KH
2007-12-13 6:34 ` [patch 10/36] I4L: fix isdn_ioctl memory overrun vulnerability Greg KH
2007-12-13 6:34 ` [patch 11/36] hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966) Greg KH
2007-12-13 6:34 ` [patch 12/36] futex: fix for futex_wait signal stack corruption Greg KH
2007-12-13 6:34 ` [patch 13/36] forcedeth: new mcp79 pci ids Greg KH
2007-12-13 6:34 ` [patch 14/36] forcedeth boot delay fix Greg KH
2007-12-13 6:34 ` [patch 15/36] fb_ddc: fix DDC lines quirk Greg KH
2007-12-13 6:34 ` [patch 16/36] TCP: Problem bug with sysctl_tcp_congestion_control function Greg KH
2007-12-13 6:34 ` [patch 17/36] TCP: MTUprobe: fix potential sk_send_head corruption Greg KH
2007-12-13 6:34 ` [patch 18/36] PFKEY: Sending an SADB_GET responds with an SADB_GET Greg KH
2007-12-13 6:34 ` [patch 19/36] NET: Corrects a bug in ip_rt_acct_read() Greg KH
2007-12-13 6:34 ` [patch 20/36] IPV4: Remove bogus ifdef mess in arp_process Greg KH
2007-12-13 6:34 ` [patch 21/36] CRYPTO api: Fix potential race in crypto_remove_spawn Greg KH
2007-12-13 6:35 ` [patch 22/36] ATM: initialize lock and tasklet earlier Greg KH
2007-12-13 6:35 ` [patch 23/36] UNIX: EOF on non-blocking SOCK_SEQPACKET Greg KH
2007-12-13 6:35 ` [patch 24/36] TEXTSEARCH: Do not allow zero length patterns in the textsearch infrastructure Greg KH
2007-12-13 6:35 ` [patch 25/36] TCP: illinois: Incorrect beta usage Greg KH
2007-12-13 6:35 ` [patch 26/36] RXRPC: Add missing select on CRYPTO Greg KH
2007-12-13 6:35 ` [patch 27/36] IPV6: Restore IPv6 when MTU is big enough Greg KH
2007-12-13 6:35 ` [patch 28/36] DECNET: dn_nl_deladdr() almost always returns no error Greg KH
2007-12-13 6:35 ` [patch 29/36] BRIDGE: Lost call to br_fdb_fini() in br_init() error path Greg KH
2007-12-13 6:35 ` [patch 30/36] knfsd: Validate filehandle type in fsid_source Greg KH
2007-12-13 6:35 ` [patch 31/36] Revert "Fix SMP poweroff hangs" Greg KH
2007-12-13 6:35 ` [patch 32/36] XFS: Make xfsbufd threads freezable Greg KH
2007-12-13 18:46 ` Fortier,Vincent [Montreal]
2007-12-13 19:07 ` Olivér Pintér
2007-12-13 19:16 ` Olivér Pintér
2007-12-14 0:34 ` Greg KH
2007-12-13 6:35 ` [patch 33/36] XFRM: Fix leak of expired xfrm_states Greg KH
2007-12-13 6:35 ` [patch 34/36] NETFILTER: xt_TCPMSS: remove network triggerable WARN_ON Greg KH
2007-12-13 6:35 ` [patch 35/36] libata: kill spurious NCQ completion detection Greg KH
2007-12-13 6:35 ` [patch 36/36] BRIDGE: Properly dereference the br_should_route_hook Greg KH
2007-12-13 6:42 ` [stable] [patch 00/36] 2.6.22-stable review Greg KH
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=20071213063353.GC25301@kroah.com \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=borntraeger@de.ibm.com \
--cc=cavokz@gmail.com \
--cc=cebbert@redhat.com \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkrufky@linuxtv.org \
--cc=npiggin@suse.de \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=zwane@arm.linux.org.uk \
/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