blob: dc9183539f7301cc2ce46775f6673a2d480242e5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, I need to figure out whether this QEMU issue is a user-mode problem or a system-mode problem. Let's start by understanding the bug report.
The user provided a code snippet where they mmap an anonymous memory region and then use madvise with MADV_DONTNEED. On Linux host, it works as expected: after the madvise call, *P becomes 0 because the pages are cleared. But when run under QEMU's user mode (qemu-x86_64), the assertion fails because *P is still 'A', meaning the memory wasn't cleared.
Looking at QEMU's code, in the linux-user/syscall.c file around line 11941, there's a comment saying that MADV_DONTNEED is just a hint and ignoring it is okay. But according to the man page for madvise, MADV_DONTNE need changes the memory semantics by repopulating or zero-filling pages.
So QEMU isn't handling MADV_DONTNEED correctly in user mode. This affects how applications behave when run under QEMU, especially those relying on this specific behavior.
Since the issue is about how system calls are handled in user mode and not related to hardware devices or higher privileges, it's a user-mode problem.
</think>
user
|