1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, I need to classify this bug report as either 'user' or 'system' mode related for QEMU. Let's go through the problem step by step.
The issue is that when running a RISC-V 32-bit chroot environment under QEMU's user emulation (qemu-user-riscv32), background jobs started by bash hang indefinitely. The strace output shows repeated waitid calls with WNOHANG, which are returning 0, causing an infinite loop.
Looking at the provided code examples, especially simple_shell.c, it uses fork and execvp to launch processes and then waits using wait4 or waitpid. The problem occurs when handling background jobs; after launching a process in the background, the shell doesn't correctly detect when the job has completed, leading to an infinite loop.
From the strace output, it seems that the waitid system call is not returning any child processes (returns 0 repeatedly), which should indicate no children have changed state. However, this might be happening incorrectly because the process might still be running or QEMU isn't handling signals properly in user mode.
QEMU's user-mode emulation deals with emulating a CPU and providing a Linux system call interface for user-space programs without running a full VM. Issues here relate to how system calls are handled, especially those involving process management like waitid, wait4, etc.
The fact that the problem is reproducible in a chroot environment under QEMU's user emulation points towards an issue with how these specific system calls are implemented or emulated in user mode. This suggests it's related to the user-mode part of QEMU rather than the system-mode which deals with hardware and full OS booting.
Additionally, the problem was mentioned in a QEMU-devel thread from 2021, which further indicates that this is an issue within QEMU's user emulation layer.
So, putting it all together: The bug is related to how waitid or similar system calls are handled in QEMU's user-mode environment when dealing with background processes. Therefore, the classification should be 'user'.
</think>
user
|