1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to classify this bug report for QEMU. The issue is that when an application uses MADV_DONTNEED, QEMU isn't handling it correctly. Let me break down what's happening here.
The user provided code where they map a page with MAP_PRIVATE | MAP_ANONYMOUS, which means it's private and anonymous—so changes won't be reflected in any file. They write 'A' to the first byte of this mapped area. Then they call madvise with MADV_DONTNEED on that region.
According to the man pages, after MADV_DONTNEED, accessing those pages should result in either reloading from a file (for shared mappings) or zero-filled pages for private anonymous mappings. In this case, since it's MAP_PRIVATE and anonymous, any access should get zeros because the OS can just drop the pages and refill them on next access with zeros.
In the code, after calling madvise, they assert that *P is 0. On the host system, this works as expected, but when run under QEMU, it fails, meaning *P isn't zeroed out, causing an assertion failure.
Looking at the QEMU code, in the syscall.c file, there's a comment saying MADV_DONTNEED is ignored because it's a hint. So QEMU just returns success without doing anything, which explains why the memory isn't cleared as expected.
So this issue is about how QEMU handles a specific system call—madvise with MADV_DONTNEED. Since it's not correctly implementing the expected behavior of the madvise syscall, it falls under a syscall error category.
</think>
The bug report pertains to an incorrect handling of the `madvise` system call in QEMU when processing the `MADV_DONTNEED` advice, leading to unexpected memory behavior.
**Answer:** The given bug is classified as a **syscall** issue.
|