On 2025/11/18 1:42, Peter Xu wrote:
On Sat, Nov 15, 2025 at 11:59:01AM +0900, Akihiko Odaki wrote:
This is wrong. The following can still happen:
call_rcu_thread() |
qatomic_sub(&rcu_call_count, n) |
(sets rcu_call_count to 0) |
| call_rcu1()
| qatomic_fetch_inc(&rcu_call_count)
qatomic_read(&rcu_call_count) |
qemu_event_reset(&sync_event) |
| qemu_event_set(&sync_event)
enter_qs(false) |
wait_for_readers(false) |
qemu_sem_timedwait( |
&sync_event, 10) |
I'll fix it with the next version.
Please take this as an example of why I think these orderings are very hard
to make 100% accurate. Consider when someone else who is less familiar
with the rcu code and may mess up with some of the orderings without being
noticed.
That's also why I personally liked a sem because the important thing here
is not missing an event, which sem always guarantees as it doesn't have
resetting at all. Then we can be open to false positives on events as long
as keeping it as minimum as possible.
It doesn't matter if it is a semaphore or event in this case. You can
simply drop qemu_event_reset(&sync_event) here and the situation will be
same for both event and semaphore.
Regards,
Akihiko Odaki
