[PATCH i-g-t v2] tests/drm_import_export: Add tests for prime/flink sharing races

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It is possible to race between unreference of the underlying BO and
importing it from prime_fd/name. Verify that the behaviour of libdrm
is consistent for prime/flink.

v2: more comments in source file, dropped extra whitespace

Signed-off-by: Michał Winiarski <michal.winiarski@xxxxxxxxx>
Cc: Thomas Wood <thomas.wood@xxxxxxxxx>
---
 tests/drm_import_export.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index 57b13dd..e24e0df 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -131,6 +131,108 @@ static void * test_thread(void * par)
 	return NULL;
 }
 
+#define IMPORT_RACE_LOOPS 100000
+
+struct import_race_thread_data {
+	int prime_fd;
+	uint32_t flink_name;
+	unsigned int stop;
+	pthread_mutex_t mutex;
+};
+
+/*
+ * Attempt to import the bo. It is possible that GEM_CLOSE was already called
+ * in different thread and from i915 point of view the handle is no longer
+ * valid (thus create_from_prime/name should fail).
+ */
+static void *import_close_thread(void *data)
+{
+	struct import_race_thread_data *t = (struct import_race_thread_data *)data;
+	drm_intel_bo *bo;
+	pthread_mutex_lock(&t->mutex);
+	while (!t->stop) {
+		pthread_mutex_unlock(&t->mutex);
+		bo = NULL;
+		if (use_flink)
+			bo = drm_intel_bo_gem_create_from_name(bufmgr, "buf-shared", t->flink_name);
+		else {
+			pthread_mutex_lock(&t->mutex);
+			if (t->prime_fd != -1) {
+				bo = drm_intel_bo_gem_create_from_prime(bufmgr, t->prime_fd, 4096);
+				pthread_mutex_unlock(&t->mutex);
+			}
+			else
+				/* We take the lock right after entering the loop */
+				continue;
+		}
+		if (bo == NULL) {
+			/*
+			 * If the bo is NULL it means that we've unreferenced in other
+			 * thread - therefore we should expect ENOENT
+			 */
+			igt_assert_eq(errno, ENOENT);
+			continue;
+		}
+
+		drm_intel_bo_unreference(bo);
+
+		pthread_mutex_lock(&t->mutex);
+	}
+	pthread_mutex_unlock(&t->mutex);
+
+	return NULL;
+}
+
+/*
+ * It is possible to race between unreference of the underlying BO and importing
+ * it from prime_fd/name. Verify that the behaviour of libdrm is consistent for
+ * prime/flink.
+ */
+static void test_import_close_race(void)
+{
+	pthread_t t;
+	unsigned int loops = IMPORT_RACE_LOOPS;
+	drm_intel_bo *bo;
+	struct import_race_thread_data t_data;
+
+	memset(&t_data, 0, sizeof(t_data));
+	pthread_mutex_init(&t_data.mutex, NULL);
+	t_data.prime_fd = -1;
+
+	igt_assert_eq(pthread_create(&t, NULL, import_close_thread , &t_data), 0);
+
+	while (loops--) {
+		bo = drm_intel_bo_alloc(bufmgr, "buf-shared", 4096, 4096);
+		igt_assert(bo != NULL);
+		/*
+		 * We setup the test in such way, that create_from_* can race between
+		 * unreference. If we're using prime, prime_fd is always a valid fd.
+		 */
+		if (use_flink)
+			igt_assert_eq(drm_intel_bo_flink(bo, &(t_data.flink_name)), 0);
+		else {
+			pthread_mutex_lock(&t_data.mutex);
+			igt_assert_eq(drm_intel_bo_gem_export_to_prime(bo, &(t_data.prime_fd)), 0);
+			igt_assert(t_data.prime_fd != -1);
+			pthread_mutex_unlock(&t_data.mutex);
+		}
+
+		drm_intel_bo_unreference(bo);
+
+		pthread_mutex_lock(&t_data.mutex);
+		close(t_data.prime_fd);
+		t_data.prime_fd = -1;
+		pthread_mutex_unlock(&t_data.mutex);
+	}
+
+	pthread_mutex_lock(&t_data.mutex);
+	t_data.stop = 1;
+	pthread_mutex_unlock(&t_data.mutex);
+
+	pthread_join(t, NULL);
+	pthread_mutex_destroy(&t_data.mutex);
+}
+
 pthread_t test_thread_id1;
 pthread_t test_thread_id2;
 pthread_t test_thread_id3;
@@ -153,6 +255,16 @@ igt_main {
 		drm_intel_bufmgr_gem_enable_reuse(bufmgr);
 	}
 
+	igt_subtest("import-close-race-flink") {
+		use_flink = true;
+		test_import_close_race();
+	}
+
+	igt_subtest("import-close-race-prime") {
+		use_flink = false;
+		test_import_close_race();
+	}
+
 	igt_subtest("flink") {
 		use_flink = true;
 
-- 
2.4.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux