On 22.09.25 16:40, Peter Maydell wrote:
On Fri, 19 Sept 2025 at 12:54, Daniel P. Berrangé <[email protected]> wrote:
From: Vladimir Sementsov-Ogievskiy <[email protected]>
Instead of open-coded g_unix_set_fd_nonblocking() calls, use
QEMU wrapper qemu_set_blocking().
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
[DB: fix missing closing ) in tap-bsd.c, remove now unused GError var]
Signed-off-by: Daniel P. Berrangé <[email protected]>
---
index fe4be6be17..e83e6c6ee9 100644
--- a/hw/misc/ivshmem-flat.c
+++ b/hw/misc/ivshmem-flat.c
@@ -154,7 +154,8 @@ static void ivshmem_flat_add_vector(IvshmemFTState *s,
IvshmemPeer *peer,
* peer.
*/
peer->vector[peer->vector_counter].id = peer->vector_counter;
- g_unix_set_fd_nonblocking(vector_fd, true, NULL);
+ /* WARNING: qemu_socket_set_nonblock() return code ignored */
+ qemu_set_blocking(vector_fd, false, &error_warn);
event_notifier_init_fd(&peer->vector[peer->vector_counter].event_notifier,
vector_fd);
What is this WARNING comment intended to mean? Is it a
TODO/bug ?
In my opinion it's a bug (preexisting): we ignore an error. We want to unblock
the fd. If we failed, most
probably it means that fd is invalid and further use of it will fail anyway..
Or something
will block on blocking operation which should be non-blocking.
The function doesn't return a value, as well as its caller, and its caller and
so on up to
qemu_chr_fe_set_handlers()...
On the other hand, at start of ivshmem_flat_add_vector(), we have
if (peer->vector_counter >= IVSHMEM_MAX_VECTOR_NUM) {
trace_ivshmem_flat_add_vector_failure(peer->vector_counter,
vector_fd, peer->id);
close(vector_fd);
return;
}
probably we can handle fd-unblocking failure the same way (and move call to
qemu_set_blocking()
to the top, to avoid any further modifications ("adding the vector"?) in case
of error.
I can send a patch, it seems safer then blindly continue using the fd.
--
Best regards,
Vladimir
