[igt-dev] [PATCH i-g-t] lib/igt_chamelium: wait for worker thread to finish
Simon Ser
simon.ser at intel.com
Wed Jun 5 10:36:27 UTC 2019
Whenever we change a pipe's resolution, we need to perform a FSM on the
Chamelium: the video receiver will be restarted and the Chamelium device will
send a hotplug event. All of this happens during the XML-RPC call.
To handle the hotplug event, we start a new thread (and execute the XML-RPC
request in the main thread in a blocking fashion). Some state is associated
with the hotplug thread and stored in fsm_monitor_args. We initialize this
state before starting the thread, and perform cleanup after cancelling it.
However pthread_cancel is asynchronous: it merely queues a cancellation request
for the thread. Thus cleaning up after pthread_cancel is racy: the thread might
still be running and using fsm_monitor_args.mon. Since this is shared memory,
this can lead to segmentation faults or strange behaviour.
This commit fixes the race by calling pthread_join before cleaning up the
state. This ensures that either the thread has been successfully cancelled,
either it has terminated.
This is an attempt to fix this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=110730
Signed-off-by: Simon Ser <simon.ser at intel.com>
---
lib/igt_chamelium.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
index 75f03d8469aa..eaf3b5b07097 100644
--- a/lib/igt_chamelium.c
+++ b/lib/igt_chamelium.c
@@ -302,6 +302,7 @@ static xmlrpc_value *__chamelium_rpc_va(struct chamelium *chamelium,
if (fsm_port) {
pthread_cancel(fsm_thread_id);
+ pthread_join(fsm_thread_id, NULL);
igt_cleanup_hotplug(monitor_args.mon);
}
--
2.21.0
More information about the igt-dev
mailing list