diff options
Diffstat (limited to 'results/classifier/105/other/1898011')
| -rw-r--r-- | results/classifier/105/other/1898011 | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/results/classifier/105/other/1898011 b/results/classifier/105/other/1898011 new file mode 100644 index 00000000..6b1bc7d5 --- /dev/null +++ b/results/classifier/105/other/1898011 @@ -0,0 +1,95 @@ +other: 0.875 +semantic: 0.835 +graphic: 0.785 +mistranslation: 0.669 +network: 0.609 +instruction: 0.597 +socket: 0.553 +assembly: 0.538 +vnc: 0.532 +device: 0.485 +KVM: 0.466 +boot: 0.447 + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM + +Run this program: + +#include <sys/mman.h> +#include <stdio.h> +int main() { + for (int i = 30; i <= 44; i++) { + fprintf(stderr, "trying 2**%d\n", i); + mmap((void*)0x600000000000,1ULL << i, + PROT_NONE, + MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0); + } +} + +(tried qemu-x86_64 and qemu-aarch64, 4.2.1 and trunk/5.1.50) + +On each iteration qemu will consume 2x more physical RAM, +e.g. when mapping 2^42 it will have RSS of 16Gb. + +On normal linux it works w/o consuming much RAM, due to MAP_NORESERVE. + +Also: qemu -strace prints 0 instead of the correct size starting from size=2^32 +and prints -2147483648 for size=2^31. + +mmap(0x0000600000000000,1073741824,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,-2147483648,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,0,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +Without actually looking, an allocation of 2**42 (4PB) requires +2**30 (1G) pages, and thus 1G page table entries, so 16GB memory +allocation sounds about right for qemu's internal page table allocation. + +We need to change data structures for representing guest memory, +probably akin to the kernel's VMAs. + +The problem occurs for example with any program which was compiled with the address sanitizer. + +A simple hello program compiled with "gcc -fsanitize=address hello.c" is sufficient to show the problem. Just run it with "qemu-x86_64 a.out". It will be killed by the Linux kernel OOM handler even on a server with 64 GB RAM. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Still an issue, yes. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/290 + + |