[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