|
|
On 06/22/2009 08:44 PM, Anthony Liguori wrote:
See attached.
Author: Anthony Liguori<aliguori@xxxxxxxxxx>
Date: Mon Jun 22 12:39:00 2009 -0500
Make sure to zero out memory before calling madvise to increase robustness
Avi pointed out that it's not entirely safe to rely on madvise zeroing out
memory. So let's do it explicitly before calling madvise.
Signed-off-by: Anthony Liguori<aliguori@xxxxxxxxxx>
diff --git a/vl.c b/vl.c
index 60a00e1..1c077b4 100644
--- a/vl.c
+++ b/vl.c
@@ -3358,13 +3358,13 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
if (flags& RAM_SAVE_FLAG_COMPRESS) {
uint8_t ch = qemu_get_byte(f);
-#if defined(__linux__)
+ memset(qemu_get_ram_ptr(addr), ch, TARGET_PAGE_SIZE);
+#ifndef _WIN32
if (ch == 0&&
(!kvm_enabled() || kvm_has_sync_mmu())) {
madvise(qemu_get_ram_ptr(addr), TARGET_PAGE_SIZE,
MADV_DONTNEED);
- } else
+ }
#endif
- memset(qemu_get_ram_ptr(addr), ch, TARGET_PAGE_SIZE);
} else if (flags& RAM_SAVE_FLAG_PAGE)
qemu_get_buffer(f, qemu_get_ram_ptr(addr), TARGET_PAGE_SIZE);
} while (!(flags& RAM_SAVE_FLAG_EOS));
Pretty similar to my December patch... which had another case, is it
missing?
http://article.gmane.org/gmane.comp.emulators.qemu/34523
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
|
|