[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
aio_wait_bh_oneshot() thread-safety question
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
aio_wait_bh_oneshot() thread-safety question |
Date: |
Mon, 23 May 2022 19:04:51 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 |
Hi all (yes, that's my new address, I hope for a long time. )
I have a doubt about how aio_wait_bh_oneshot() works. Exactly, I see that
data->done is not accessed atomically, and doesn't have any barrier protecting
it..
Is following possible:
main-loop iothread
|
aio_wait_bh_oneshot() |
aio_bh_schedule_oneshot() |
| handle bh:
| 1. set data->done = true
| 2. call aio_wait_kick(), inserting the
| dummy bh into main context
|
... in AIO_WAIT_WHILE():
handle dummy bh, go to next
iteration, but still read
data->done=false due to some
processor data reordering,
go to next iteration of polling
and hang
?
I've seen a following dead-lock on 2.12-based Qemu, but failed to find is it
(and how is it) fixed in master:
1. main() thread is stuck in qemu_mutex_lock_iothread()
2. The global mutex is taken by migration_thread(), which has the following
stack:
aio_poll ( ctx=qemu_aio_context, blocking=true )
aio_wait_bh_oneshot ( ctx=context_of_iothread, cb=virtio_blk_data_plane_stop_bh
)
virtio_blk_data_plane_stop
virtio_bus_stop_ioeventfd
virtio_vmstate_change
vm_state_notify
do_vm_stop
migration_completion
The iothread itself is in qemu_poll_ns() -> ppoll(). data->done of the BH is true,
so I assume iothread completely handled the BH. Also, there is no dummy_bh in the main
qemu aio context bh-list, so I assume it's either already handled, or aio_wait_kick()
was called even before entering AIO_WAIT_WHILE. But still, AIO_WAIT_WHILE somehow go
into block aio_poll, like data->done was false.
--
Best regards,
Vladimir
- aio_wait_bh_oneshot() thread-safety question,
Vladimir Sementsov-Ogievskiy <=