blob: 9c408ab0fd4b8185cb90347cf4e8950aff1e7c37 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I'm trying to figure out whether this bug report about netlink being broken on big-endian MIPS in QEMU is a user-mode or system-mode issue. Let me break down the information provided.
The problem occurs when running Debian inside a chroot using QEMU's user mode emulator (qemu-mips-static). When executing 'ip route', it hangs. The strace shows that the process is stuck waiting for a netlink response, which never comes. Looking at the sendto call, the len field in the buffer is 0x28000000, which looks like a byteswapped value, suggesting an endianess issue.
The user provided a patch where they removed the fd_trans_unregister call after do_socket in the syscall handler. This seems to fix the problem for them. The comment mentions that this was added for a reason, so it's unclear why unregistering the file descriptor translation would cause issues.
QEMU has two main modes: system-mode and user-mode. System-mode emulates an entire machine with its own kernel, while user-mode translates syscalls from the target architecture to the host's syscalls without running a separate kernel.
In this case, since it's using qemu-mips-static, which is the user-mode emulator, the issue likely lies in how QEMU handles netlink socket operations in user mode. The fact that removing fd_trans_unregister fixes it suggests there's an incorrect handling of file descriptor translations for sockets in user-mode.
Therefore, this bug is related to user-mode because it involves how QEMU translates system calls and manages file descriptors for the target architecture when running applications in a chroot environment.
</think>
user
|