aboutsummaryrefslogtreecommitdiff
path: root/arch/cris/arch-v10/drivers
diff options
context:
space:
mode:
authorChristian Borntraeger <borntraeger@de.ibm.com>2007-11-14 17:00:05 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-11-14 18:45:42 -0800
commit5d0360ee96a5ef953dbea45873c2a8c87e77d59b (patch)
tree61270c84623618638a5abe0957d90ee9545e9c92 /arch/cris/arch-v10/drivers
parent822bd5aa2b8e8fa1d328f03bf5b9c75701481bf0 (diff)
rd: fix data corruption on memory pressure
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> 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>
Diffstat (limited to 'arch/cris/arch-v10/drivers')
0 files changed, 0 insertions, 0 deletions