[Top][All Lists]

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

Re: [Qemu-devel] [PATCH RFC v3 7/7] qemu_thread_create: propagate the er

From: Fei Li
Subject: Re: [Qemu-devel] [PATCH RFC v3 7/7] qemu_thread_create: propagate the error to callers to handle
Date: Thu, 20 Sep 2018 18:27:20 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 09/20/2018 03:32 PM, Fam Zheng wrote:
On Wed, 09/19 23:51, Fam Zheng wrote:
diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index d7a4bbd91f..e7cbb0c368 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -165,7 +165,8 @@ static void start_comp_thread(RdmaBackendDev *backend_dev)
      backend_dev->comp_thread.run = true;
      qemu_thread_create(&backend_dev->comp_thread.thread, thread_name,
-                       comp_handler_thread, backend_dev, QEMU_THREAD_DETACHED);
+                       comp_handler_thread, backend_dev,
+                       QEMU_THREAD_DETACHED, &error_abort);
Previously we don't abort() QEMU if a new thread cannot be created. I think we
want some more robustness here. Peter?
Looking more closely, this is not migration code, but device code. So it doesn't
hurt as much, but still, in the longer term we may want to handle the error
instead of abort(). E.g. in activate_device() set an error state. A task for a
separate series, though. So this patch can be kept as is, or add a FIXME

Yes, this is a device code. But as I am not familiar with the rdma stuff and adding error handling in activate_device() may involve the interrupt handling, I'd prefer to
add a FIXME comment. :)

Have a nice day, thanks again

reply via email to

[Prev in Thread] Current Thread [Next in Thread]