1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I need to classify this bug report as either 'user-mode' or 'system-mode'. Let me try to understand the problem first.
The user ran a command in an amd64 Docker image on s390x hardware. The command was "perf bench futex lock-pi", which resulted in an ENOSYS error. From what I know, ENOSYS means that the system call isn't implemented.
Looking at the steps, they executed this in a Docker container. Docker typically runs user-space processes. So, why is there an issue with a system call?
The error message mentions FUTEX_LOCK_PI. That's a futex operation which is a system call used for locking. The code called the syscall(SYS_futex, ...) function. System calls are part of the kernel.
So, if the system call isn't implemented, that suggests it's an issue with the kernel not supporting this particular futex operation on s390x architecture when running in user-mode emulation via QEMU. Since Docker runs containers within the host's kernel, but in this case, since it's a different architecture (s390x) and using QEMU-x86_64-static for x86_64 emulation, maybe the system call isn't properly handled.
QEMU is involved here because it's emulating an x86_64 environment on s390x. If the kernel in use (probably from Docker or the host) doesn't support FUTEX_LOCK_PI when running under QEMU-x86_64-static, that would cause ENOSYS.
Since the issue arises because a system call isn't implemented in the environment provided by QEMU and possibly the underlying kernel setup for the container, this seems like it's related to how the virtualization is handling the system calls. Therefore, it might be a user-mode problem if it's about how QEMU is emulating the x86_64 system calls on s390x.
Alternatively, if the host kernel doesn't support FUTEX_LOCK_PI when run in this setup, it could be a system-mode issue. But since Docker and QEMU are more about user-space emulation, I'm leaning towards 'user' because it's about how the emulated environment handles the calls.
</think>
The bug is related to how QEMU-x86_64-static handles FUTEX_LOCK_PI in an amd64 Docker image on s390x. It involves system call handling in user-mode emulation.
user
|