search for: accept_incoming_connections

...c550, nfds=nfds at entry=2, timeout=timeout at entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00005577156b9646 in poll (__timeout=-1, __nfds=2, __fds=<optimized out>) at /usr/include/bits/poll2.h:46 #2 check_sockets_and_quit_fd (nr_socks=1, socks=0x55771f18c2e0) at sockets.c:466 #3 accept_incoming_connections (socks=0x55771f18c2e0, nr_socks=1) at sockets.c:494 #4 0x00005577156ac6ac in start_serving () at main.c:914 #5 main (argc=<optimized out>, argv=0x7ffd0bcb15d8) at main.c:685 Thread 1 (Thread 0x7f12b820e700 (LWP 231469)): #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/rai...

...kets.c:356 #6 0x00007fabc069d472 in start_thread () from /lib64/libpthread.so.0 #7 0x00007fabc05cc063 in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fabc002ca40 (LWP 3955770)): #0 0x00007fabc06a3b02 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00005583f90d6dbf in accept_incoming_connections (socks=0x5584020bf010, nr_socks=1) at sockets.c:501 #2 0x00005583f90ca441 in start_serving () at main.c:936 #3 main (argc=<optimized out>, argv=<optimized out>) at main.c:702 The stack trace of [1] at the hang is: Thread 2 (Thread 0x7f30ac822700 (LWP 3955798)): #0 0x00007f30b32a384...

.../main.c index 5623149..935d422 100644 --- a/server/main.c +++ b/server/main.c @@ -857,6 +857,7 @@ start_serving (void) for (i = 0; i < nr_socks; ++i) socks[i] = FIRST_SOCKET_ACTIVATION_FD + i; change_user (); + backend->ready_to_serve (backend); write_pidfile (); accept_incoming_connections (socks, nr_socks); free_listening_sockets (socks, nr_socks); /* also closes them */ @@ -866,6 +867,7 @@ start_serving (void) /* Handling a single connection on stdin/stdout. */ if (listen_stdin) { change_user (); + backend->ready_to_serve (backend); write_pidfile ();...

...ing into module memory; and threadlocal_set_name() should strdup() the name rather than relying on the lifetime of the storage of whatever the caller passed in (either fix in isolation solves that SEGV, but using both seems like a good idea). We also have a race that results in a hang in sockets.c:accept_incoming_connections(); if I understand the problem, it is something like: main signal context -------------------------------------- first iteration, finish accept_connect() checks !quit, starts second iteration SIGTERM received set quit call poll()...

...d (int *socks, size_t nr_socks) > { > - struct pollfd fds[nr_socks + 1]; > size_t i; > int r; > > + CLEANUP_FREE struct pollfd *fds = > + malloc (sizeof (struct pollfd) * (nr_socks+1)); This is indeed safer, but adds a malloc() in a loop. Thankfully, the loop of accept_incoming_connections() doesn't cycle that quickly (once per new client), so I think it's in the noise compared to pre-allocating the array once before starting the loop. ACK. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

I've posted some of these patches or ideas before; but now I'm confident enough with the series that it should be ready to push; at any rate, I can now run test-socket-activation in a tight loop without triggering any crashes or hangs. With this in place, I'm going back to work on making the nbd forwarder wort with the parallel thread model. Eric Blake (8): sockets: Use

...e__((__nonnull__ (1))); +extern void unlock_request (struct connection *conn) + __attribute__((__nonnull__ (1))); extern void lock_unload (void); extern void unlock_unload (void); /* sockets.c */ -extern int *bind_unix_socket (size_t *); -extern int *bind_tcpip_socket (size_t *); -extern void accept_incoming_connections (int *socks, size_t nr_socks); -extern void free_listening_sockets (int *socks, size_t nr_socks); +extern int *bind_unix_socket (size_t *) + __attribute__((__nonnull__ (1))); +extern int *bind_tcpip_socket (size_t *) + __attribute__((__nonnull__ (1))); +extern void accept_incoming_connections (in...

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also in highly multithreaded code with limited stack sizes (as nbdkit

...ver/internal.h +++ b/server/internal.h @@ -454,6 +454,8 @@ extern int *bind_unix_socket (size_t *) __attribute__((__nonnull__ (1))); extern int *bind_tcpip_socket (size_t *) __attribute__((__nonnull__ (1))); +extern int *bind_vsock (size_t *) + __attribute__((__nonnull__ (1))); extern void accept_incoming_connections (int *socks, size_t nr_socks) __attribute__((__nonnull__ (1))); extern void free_listening_sockets (int *socks, size_t nr_socks) diff --git a/server/main.c b/server/main.c index 5623149..115fa98 100644 --- a/server/main.c +++ b/server/main.c @@ -45,6 +45,11 @@ #include <syslog.h> #inclu...

v1 was discussed here: https://www.redhat.com/archives/libguestfs/2019-October/thread.html#00100 v2: - Bind to VMADDR_CID_ANY (instead of HOST) and update the documentation accordingly. - Don't bother with SOCK_CLOEXEC fallback path that can never be used. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-January/msg00008.html In v2 I have provided two patches: The first patch extends attribute((nonnull)) to most internal functions, but not to the external API. The second patch uses a macro so that attribute((format)) is only used in the public API on GCC or Clang. At least in theory these headers could be used by a C compiler which

This fixes the race conditions for me, using the test described here: https://www.redhat.com/archives/libguestfs/2017-September/msg00226.html Rich.

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

...erver/main.c b/server/main.c index e9f95380..c432f5bd 100644 --- a/server/main.c +++ b/server/main.c @@ -959,6 +959,7 @@ start_serving (void) debug ("using socket activation, nr_socks = %zu", socks.size); change_user (); write_pidfile (); + top->after_fork (top); accept_incoming_connections (&socks); return; } @@ -967,6 +968,7 @@ start_serving (void) if (listen_stdin) { change_user (); write_pidfile (); + top->after_fork (top); threadlocal_new_server_thread (); handle_single_connection (saved_stdin, saved_stdout); return; @@ -986,6 +988,7...

...quot;, nr_socks); + socks = malloc (sizeof (int) * nr_socks); + if (socks == NULL) { + perror ("malloc"); + exit (EXIT_FAILURE); + } + for (i = 0; i < nr_socks; ++i) + socks[i] = FIRST_SOCKET_ACTIVATION_FD + i; + change_user (); + write_pidfile (); + accept_incoming_connections (socks, nr_socks); + free_listening_sockets (socks, nr_socks); /* also closes them */ + return; + } + /* Handling a single connection on stdin/stdout. */ if (listen_stdin) { change_user (); @@ -752,3 +806,60 @@ parsegroup (const char *id) return grp->gr_gid; } + +/* Retur...

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

This is an incomplete port to Windows. Currently the server compiles and starts up successfully, but goes into an infinite loop when you connect to it. Nevertheless I think the approach is ready for feedback. This being Windows the changes go quite deep. Rich.

...ib64/libpthread.so.0 #5 0x00007fc4b9c55b23 in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7fc4b96bb200 (LWP 109858)): #0 0x00007fc4b9c4aa2f in poll () from /lib64/libc.so.6 #1 0x0000000000418af3 in check_sockets_and_quit_fd (socks=0x7ffe7d9b3b80) at sockets.c:447 #2 0x0000000000418bd7 in accept_incoming_connections (socks=0x7ffe7d9b3b80) at sockets.c:475 #3 0x000000000040f6c9 in start_serving () at main.c:974 #4 0x000000000040ef8b in main (argc=9, argv=0x7ffe7d9b3de8) at main.c:736 Thread 5 (Thread 0x7fc4a921d640 (LWP 109872)): #0 0x00007fc4b9c464ef in write () from /lib64/libc.so.6 #1 0x00007fc4b9bd5e5d...

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw-nolib After a lot of work I have made the port to Windows work without using a separate library. Instead, on Windows only, we build an "import library" (library of stubs) which resolves references to nbdkit_* functions in the main program and fixes up the plugin, basically the first technique outlined in