blob: d6ab3a15cb4706a24e8666e691ebda37249ca440 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to classify this bug report as either user-mode or system-mode related. Let's break down the information provided.
The issue is about mmap exhaustion when using a Linux-user target in QEMU. The problem arises because each mmap call uses an accumulator approach, which leads to quickly burning through address space, especially on a 64-bit host with a 32-bit target. This causes failures when processes like rpmbuild, which use many FILE handles and thus multiple mmaps, run into this issue.
The solution proposed is a patch that checks if the end of a munmap call aligns with the next allocation point. If so, it resets the starting point to reuse the freed space. The developer mentions that this fix has worked for their case but still points out that there are other potential triggers, like a specific bug in MeeGo.
Now, considering whether this is user-mode or system-mode: User-mode emulation in QEMU deals with executing guest programs without requiring a full OS. System-mode, on the other hand, involves emulating an entire system, including hardware and device drivers, typically at higher privilege levels.
In this case, the problem is within mmap.c which is part of the user-mode setup since it's about handling memory mappings for the guest processes running under Linux-user. The patch modifies how mmap allocations are handled without involving lower-level system calls or hardware emulation. Therefore, it fits within the user-mode category.
</think>
user
|