1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, let me try to figure out how to classify this bug report. The user is reporting an issue with QEMU where using the `device_add` command causes a deadlock. They mentioned that it hangs and only stopping via `kill -9` works.
Looking at the details, they traced the problem to functions related to RCU (Read-Copy-Update). Specifically, `drain_call_rcu` is waiting indefinitely for `drain_complete_event`. Also, `cpu_exec` in `accel/tcg/cpu-exec.c` calls `rcu_read_lock` but doesn't unlock it properly. This could mean that the lock isn't being released, leading to a deadlock because other parts of the code are waiting on it.
Another point is that when they use the `stop` command before `device_add`, there's no hang. That suggests that `cpu_exec` might be in a state where it's not releasing locks properly during certain operations.
Now, considering the possible categories: The issue seems related to how RCU is being handled, which ties into concurrency and synchronization within QEMU. Since this involves kernel-level functions like `rcu_read_lock`, it's likely part of the hypervisor's operation. Hypervisors handle tasks like device management, CPU execution, and other low-level operations where proper locking and unlocking are critical.
So, putting it all together, the category that best fits is "hypervisor" because the bug occurs in functions that manage resources at a low level, likely within QEMU's hypervisor component.
</think>
The issue involves deadlocks due to improper RCU handling during device addition, which relates to low-level resource management in QEMU's hypervisor.
hypervisor
|