If we allow listening on arbitrary sockets like unix sockets,
we can get ENOPROTOOPT errors from setsockopt calls that set TCP
specific options. This should be allowed to happen.
Commit 143a1df24e changed red_worker_main
from epoll to poll. But epoll has edge triggered semantics (when requested
and we requested them), where as poll is always level triggered. And
red_worker was relying on the edge triggered semantics, as it was always
polling for POLLOUT, which, when edge triggered, would only cause poll
to register an event after we had blocked on a write. But after the
switch to regular poll, with its level triggered semantics, the POLLOUT
condition would almost always be true, causing red_worker_main to not
block on the poll and burn CPU as fast as it can as soon as a client was
connected.
Luckily we already have a mechanism to switch from polling for read only
to polling for read+write and back again in the form of watches. So this
patch changes the red_worker dummy watch implementation into a proper watch
implementation, and drops the entire EventListener concept since that then is
no longer needed.
This fixes spice-server using 400% CPU on my quad core machine as soon as
a client was connected to a multi head vm, and as an added bonus is a nice
cleanup IMHO.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We allow channels to have different core implementations, but we were
relying on reds_stream_free to remove the stream watch on disconnect,
and reds_stream_free always uses the qemu core implementation.
So far we were getting away with this since all the alternative core
implementations always return NULL from watch_add.
But:
1) The code before this patch clearly was not correct, since it was matching
a channel-core watch_add with a qemu-core watch_remove
2) I plan to move red_worker over to actually using an alternative watch
implementation at which point this becomes a real problem
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The red_worker EventListener struct is either embedded in one of:
1) DisplayChannelClient
2) CursorChannelClient
3) RedWorker
And as such gets destroyed when these get destroyed, in case 1 & 2 through
a call to red_channel_client_destroy().
So free-ing it when the ref-count becomes 0 is wrong, for cases:
1) and 2) this will lead to a double free;
3) this will lead to passing memory to free which was not returned by malloc.
This is not causing any issues as the ref-count never gets decremented, other
then in red_worker_main where it gets incremented before it gets decremented,
so it never becomes 0.
So we might just as well completely remove it.
Notes:
1) This is mainly a preparation patch for fixing issues introduced by
the move from epoll to poll
2) Since removing the ref-counting removes the one code path where listeners
would get set to NULL, this patch moves the setting of NULL to
pre_disconnect, where it should have been done in the first place since
red_client_destroy calls red_channel_client_disconnect
(through the dispatcher) followed by red_channel_client_destroy, so
after pre_disconnect the listener may be gone.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
While git-bisecting another issue I ended up hitting and not recognizing
the bug fixed by commit 7a079b452b.
While fixing this (again) I noticed that (even after the fix) not all
users of ChannelCbs first zero it. So this patch ensures that all users of
ChannelCbs first zero it, and does the same for ClientCbs while at it.
Since before this patch there were multiple zero-ing styles, some using
memset and other using a zero initializer this patch also unifies all
the zero-ing to use a NULL initializer for the first element.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This fixes a core dumped observed once by repeated migration. So far 100
migrations and no recurrence.
Core was generated by `/home/alon/spice/upstream/bin/qemu-system-x86_64 --enable-kvm -qmp unix:/tmp/mi'.
Program terminated with signal 11, Segmentation fault.
11197 if (evt_listener && evt_listener->refs > 1) {
Missing separate debuginfos, use: debuginfo-install bluez-libs-4.98-3.fc17.x86_64 brlapi-0.5.6-4.fc17.x86_64 bzip2-libs-1.0.6-4.fc17.x86_64 cryptopp-5.6.1-6.fc17.x86_64 keyutils-libs-1.5.5-2.fc17.x86_64 libssh2-1.4.0-1.fc17.x86_64 nss-softokn-freebl-3.13.1-20.fc17.x86_64 xen-libs-4.1.2-11.fc17.x86_64 xz-libs-5.1.1-2alpha.fc17.x86_64
(gdb) bt
(gdb) l
11192 for (i = 0; i < MAX_EVENT_SOURCES; i++) {
11193 struct pollfd *pfd = worker.poll_fds + i;
11194 if (pfd->revents) {
11195 EventListener *evt_listener = worker.listeners[i];
11196
11197 if (evt_listener && evt_listener->refs > 1) {
11198 evt_listener->action(evt_listener, pfd);
11199 if (--evt_listener->refs) {
11200 continue;
11201 }
(gdb) p evt_listener
$1 = (EventListener *) 0x7f15a9a5d1e0
(gdb) p *evt_listener
Cannot access memory at address 0x7f15a9a5d1e0
(gdb) p i
$2 = 2
(gdb) p worker.listeners
$3 = {0x7f15bc832520, 0x7f15a406e1a0, 0x7f15a9a5d1e0, 0x0 <repeats 17 times>}
Add spice_server_set_name() and spice_server_set_uuid() that allows
the client to identify a Spice server (useful to associate settings
with a particular server)
The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent
to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
Currently, when a ticket has already expired, or is invalid, there is
no qemu log to tell what went wrong. This commit adds such a log.
Fixes rhbz#787669
- Do not refer to .c files managed by another makefile (this will fail
make distclean)
- Do not refer to files by relative path (should use $top_srcdir for ex)
- Use LDADD for object linking instead of LDFLAGS, for linker flags
Now, cursor is being shown in all tests as a white rectangle and is
running in the screen doing a diagonal movement. It's a very simple
way to test cursor commands and is sufficient for our tests.
This is provided by <limits.h> on all platforms as long as _XOPEN_SOURCE
is defined. On Linux, this is 1024, on Solaris, this is 16, and on any
other platform, we now respect the value supported by the OS.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Solaris has a pitiful maximum writev vector size of only 16, so the ping
request at initial startup destroyed this call and broke things
immediately. Reimplement stream_writev_cb() to respect IOV_MAX and break
the writev() calls into chunks as necessary. Care was taken to return
the correct values as necessary so the EAGAIN handling logic can
determine where to resume the writev call the next time around.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
This removes the epoll dependency we had in red_worker, which was the
last Linux-specific call we were using in the entire Spice server. Given
we never have more than 10 file descriptors involved, there is little
performance gain had here by using epoll() over poll().
The biggest change is introduction of a new pre_disconnect callback;
this is because poll, unlike epoll, cannot automatically remove file
descriptors as they are closed from the pollfd set. This cannot be done
in the existing on_disconnect callback; that is too late as the stream
has already been closed and the file descriptor lost. The on_disconnect
callback can not be moved before the close and other operations easily
because of some behavior that relies on client_num being set to a
certain value.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Rather than assign the callbacks one-by-one, we can just memcpy the
struct into the one we have allocated in our RedChannel object, which is
much more efficient, not to mention future-proof when more callbacks are
added.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
We had multiple stub methods that simply called other disconnect
methods, making my head hurt with the indirection. Call the right
methods at the right time and rip out the stub methods; if they are
truely needed later they can be added again.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
With future patches in mind that will allow for some other
non-Linux-specific event polling sytem to be used, rename this to a more
generic name. All of the select/poll/epoll/kqueue family of calls are
related to evented I/O, so 'event_' makes sense in this case.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
This is supported by the GNU linker, but not the Solaris linker, which
is used as the default on that platform even when compiling with GCC.
Omit passing the option to the linker on platforms that do not support
it.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
spicevmc calls red_channel_client_destroy() on the rcc when it disconnects
since we don't want to delay the destroy until the session gets closed as
spicevmc channels can be opened, closed and opened again during a single
session.
This causes red_channel_client_destroy() to get called twice, triggering
an assert, when a connected channel gets destroyed.
This was fixed with commit ffc4de01e6 for
the case where: a spicevmc channel was open on client disconnected, and
the main channel disconnect gets handled first.
But the channel can also be destroyed when the chardev gets unregistered
with the spice-server. This path still triggers the assert.
This patch fixes this by adding a destroying flag to the rcc struct, and
also moves the previous fix over to the same, more clean, method of
detecting this special case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
fixes rhbz 790749 use after free of SpiceChannelEventInfo.
The lifetime of the SpiceChannelEventInfo was that of RedsStream, but it
is used by main_dispatcher_handle_channel_event after the RedsStream is
freed for the cursor and display channels. Making SCEI allocation be at
RedsStream allocation, and deallocation after the DESTROY event is
processed by core->channel_event, fixes use after free.
red_printf() takes care of adding a newline to all messages; remove the
extra newline from all messages and macros that were doubling them up.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
As suggested by Alon, a simple automated test to try to find
regressions in Spice code.
To use this, compile Spice with --enable-automated-tests and
run test_display_streaming passing --automated-tests as parameter.
Some non-Linux platforms return a (caddr_t *) result for the return
value of mmap(), which is very unfortunate. Add a (void *) cast to
explicitly avoid the warning when compiling with -Werror.
For the IO vector related stuff, signed vs. unsigned comes into play so
adding a (void *) cast here is technically correct for all platforms.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
dc7855967f did this for the TCP_NODELAY and IP_TOS calls; we should do
it for priority as well if necessary.
We also #ifdef the setting of the low-level socket priority based on
whether we have a definition of SO_PRIORITY available. This option is
not available on Illumos/Solaris platforms; however, since we set IP_TOS
anyway it is not a big deal to omit it here.
output to send a SIGIO signal to the running program. However, we don't
handle this signal anywhere in the code, so setting the option is
unnecessary.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
With Daniel P. Berrange's patches to allow use of pre-supplied fd's
as channels, we can no longer be sure that our connections are TCP
sockets, so it makes no sense to complain if a TCP/IP specific
setsockopt fails with an errno of ENOTSUP.
Note that this extends Daniel's commit 492ddb5d1d
which already added the same check to server/inputs_channel.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Since free() takes a void* parameters do not need to be cast.
The existing code here is actally fine, but it trips up the
syntax-check rule, so tweak it to an equivalent construct
which passes the syntax check
Support for a header without a serial and without sub list.
red_channel: Support the two types of headers.
Keep a consistent consecutive messages serial.
red_worker: use urgent marshaller instead of sub list.
snd_worker: Sound channels need special support since they still don't use
red_channel for sending & receiving.
When red_channel::red_channel_client_begin_send_message is called,
the message that is pending in the urgent marshaller will be sent before
the one in the main channel.
The urgent marshaller should be used if in the middle of marshalling one message,
you find out you need to send another message before. This functionality
is equivalent to the sub_list messages. It will replace them in the following
patches, when sub_list is removed from Spice data header.
If setting the TCP_NODELAY socket option fails with ENOTSUP,
then don't treat this is a fatal error. SPICE is likely just
running over a UNIX socket instead.
* server/inputs_channel.c: Ignore TCP_NODELAY socket opt fails
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When an applications passes in a pre-accepted socket for a
client, they may well have already performed suitable authentication
out of band. They should thus have the option to request that any
spice authentication is skipped.
* server/reds.c, spice.h: Add flag for skipping auth
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Allow applications to pass a pre-accepted client socket file
descriptor in. The new APIs are spice_server_add_ssl_client
and spice_server_add_client
* server/reds.c: Implement new APIs
* server/spice.h: Define new APIs
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
To allow setup of an SSL client, from a passed in client
socket, move all the SSL client initialization code out
of reds_accept_ssl_connection and into a new method called
reds_init_client_ssl_connection
* server/reds.c: Introduce reds_init_client_ssl_connection
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Remove the accept() call from __reds_accept_connection and
rename it to reds_init_client_connection. The caller is now
responsible for accepting the new socket. The method
reds_init_client_connection merely initializes it for
usage.
* server/reds.c: Add reds_init_client_connection
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Neither reds_accept_connection or reds_accept are very long,
so the split is pointless & increases code size for no gain.
Merge them together to reduce code size
* server/reds.c: Merge reds_accept_connection into reds_accept
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The display channel was unnecessarily set to NULL when we disconnect all the clients
(on flush display commands timeout).
As a result, we recreated the display channel when a new client was connected.
The display channel was created with default red_channel.client_cbs, while its
correct client_cbs are the ones that are set by the red_dispatcher when it creates
the first display_channel.
This fix enforces a single creation of the display channel (per qxl), via the red_dispatcher.
Currently when the main channel disconnects while a spicevmc channel
(such as a usbredir channel) is still connected, qemu will abort with the
following message:
ring_remove: ASSERT item->next != NULL && item->prev != NULL failed
This is caused by red_client_destroy() first calling:
rcc->channel->client_cbs.disconnect(rcc);
And then calling:
red_channel_client_destroy(rcc);
For each channel. This is fine, but the spicevmc disconnect code does a
red_channel_client_destroy(rcc) itself since as usb devices are added
/ removed, the channels carrying their traffic get connected / disconnected
and they get re-used for new devices, which won't work if the old channel is
still there when the new connection comes in.
This patch fixes the double destroy when there are still spicevmc channels
connected by not doing the red_channel_client_destroy from the spicevmc
disconnect code when not just the channel, but the entire client is
disconnecting.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Also fixup the header of server/red_parse_qxl.c, which still contained
some GPL (program rather then library) text in its header.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
spice_server_migrate_connect is in 0.8.3 in the released 0.8 branch,
and so should not be changed in 0.10. This doesn't break the 0.9.1
release which didn't contain this symbol at all, only 0.9.2 release
that hopefully no one actually packaged.
This patch reuses Dispatcher in RedDispatcher. It adds two helpers
to red_worker to keep RedWorker opaque to the outside. The dispatcher is
abused in three places that use the underlying socket directly:
once sending a READY after red_init completes
once for each channel creation, replying with the RedChannel instance
for cursor and display.
FDO Bugzilla: 42463
rfc->v1:
* move callbacks to red_worker.c including registration (Yonit)
* rename dispatcher to red_dispatcher in red_worker.c and red_dispatcher.c
* add accessor red_dispatcher_get_dispatcher
* s/dispatcher_handle_recv/dispatcher_handle_recv_read/ and change sig to
just Dispatcher *dispatcher (was the SpiceCoreInterface one)
* remove SpiceCoreInterface parameter from dispatcher_init (Yonit)
* main_dispatcher needed it for channel_event so it has it in
struct MainDispatcher
* add dispatcher_get_recv_fd for red_worker
used for main_dispatcher only in this patch.
Dispatcher is meant to be used for Main<->any low frequency messages.
It's interface is meant to include the red_dispatcher usage:
fixed size messages per message type
some messages require an ack
Some methods are added to be used by RedDispatcher later:
dispatcher_handle_read - to be called directly by RedDispatcher epoll
based loop
dispatcher_set_opaque - to be set from red_worker pthread
dispatcher_init - allow NULL core as used by red_worker
Read and Write behavior:
Sender: blocking write, blocking read for ack (if any).
Reader: poll for any data, if such then blocking read for a
message_type and following message. repeat until poll returns
with no pending data to read.
FDO Bugzilla: 42463
This is part of the dispatcher update, extracting the dispatcher routine
from red_dispatcher and main_dispatcher into dispatcher.
Supporting multiple async operations will make it natural to support
async monitor commands and async guest io requests that could overlap in
time.
Use a Ring for AsyncCommands.
Free Desktop Bugzilla: 42463
Related FD: 41622
We will add a qemu call to spice_server_migrate_start when migration starts.
For now, it does nothing, but we may need this notification in the future.
(cherry picked from commit b821316771 branch 0.8)
(1) not sending anything to a migrated client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new client migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END
from the previous migration was received for this client
(3) use the correct ticket
Note: we assume the same channles are linked before and ater migration. i.e.,
SPICE_MSGC_MAIN_ATTACH_CHANNELS is not sent from the clients.
If the migration has completed successfully:
(1) send MSG_MAIN_MIGRATE_END to the clients that are connected to the target
(2) send MSG_MAIN_SWITCH_HOST to all the other clients
If the migration failed, send MSG_MAIN_MIGRATE_CANCEL to clients that are
connected to the target.
(cherry picked from commit 4b82580fc3 branch 0.8;
Was modified to support multiple clients, and the separation of main_channel from reds)
Conflicts:
server/reds.c
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(to all the clients that support it)
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients,
or a timeout, in order to complete client_migrate_info monitor command
(cherry picked from commit 5560c56ef0 branch 0.8;
Was modified to support the separation of main channel from reds, and multiple clients)
Conflicts:
server/reds.c
semi-seamless migration details:
migration source side
---------------------
(1) spice_server_migrate_connect (*): tell client to link
to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN.
This should be called upon client_migrate_info cmd.
client_migrate_info is asynchronous.
(2) Complete spice_server_migrate_connect only when the client has been connected
to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout.
(3) spice_server_migrate_end: tell client migration it can switch to the target - send
SPICE_MSG_MAIN_MIGRATE_END.
(4) client cleans up all data related to the connection to the source and switches to the target.
It sends SPICE_MSGC_MAIN_MIGRATE_END.
migration target side
---------------------
(1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0)
(2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END
from the client.
* After migration starts, the target qemu is blocked and cannot accept new spice client
connections. Thus, we trigger the connection to the target upon client_migrate_info
command.
(cherry picked from commit 6e56bea67c branch 0.8)
Conflicts:
server/spice.h
The code for setting and testing channel capabilities was
unnecessarily duplicated. Now it is in red_channel.
RedsChannel was dropped from Reds; It was used only for holding
the channels common capabilities, which are now held in RedChannel.
add main_dispatcher, a message passing mechanism for sending messages to
the main thread. The main thread is the thread that implements
SpiceCoreInterface, which is assumed to be a single thread.
Similar to the async operation of red_worker, a socket pair is created
and used to pass messages. The messages are a fixed size to ease
parsing. A single message is defined to pass a channel_event.
RHBZ: 746950
FDBZ: 41858
This patch is 0.8 branch only, for the master branch there should be a
better approach to share code with red_dispatcher and ready the way for
later adding more threads.
cherry-pick from 0.8 80caf07e09
Conflicts:
server/reds.c
When running some xinerama tests, I got several
glz_usr_free_image: error
messages. Looking at the code, this error is reported when this
function is called from a different DisplayChannelClient than the
one which created the glz compressed image.
When this happens, the backtrace is
at glz_encoder_dictionary.c:362
0x7fff940b6670) at glz_encoder_dictionary.c:449
image_type=LZ_IMAGE_TYPE_RGB32, image_width=512, image_height=256, image_stride=2048, first_lines=0x0,
num_first_lines=0, usr_image_context=0x7fff7420da40, image_head_dist=0x7fff9b2a3194)
at glz_encoder_dictionary.c:570
top_down=4, lines=0x0, num_lines=0, stride=2048, io_ptr=0x7fff740ea7c0 " ZL", num_io_bytes=65536, usr_context=
0x7fff7420da40, o_enc_dict_context=0x7fff7420da60) at glz_encoder.c:255
drawable=0x7fff9b46bc08, o_comp_data=0x7fff9b2a3350) at red_worker.c:5753
0x7fff9b46bc08, can_lossy=0, o_comp_data=0x7fff9b2a3350) at red_worker.c:6211
0x7fff9b46bc08, can_lossy=0) at red_worker.c:6344
0x7fff74085c50, dpi=0x7fff7445b890, src_allowed_lossy=0) at red_worker.c:7046
0x7fff7445b890) at red_worker.c:7720
at red_worker.c:7964
at red_worker.c:8431
Since the glz dictionary is shared between all the
DisplayChannelClient instances that belong to the same client, it can
happen that the glz dictionary code decides to free an image from one
thread while it was added from another thread (thread ==
DisplayChannelClient), so the error message that is printed is not an
actual error. This commit removes this message and adds a comment
explaining what's going on.
Several functions in server/ were not specifying an argument list,
ie they were declared as void foo(); When compiling with
-Wstrict-prototypes, this leads to:
test_playback.c:93:5: erreur: function declaration isn’t a prototype
[-Werror=strict-prototypes]
red_display_marshall_stream_start initializes a
SpiceMsgDisplayStreamCreate structure before marshalling it and
sending it on the wire. However, it never fills
SpiceMsgDisplayStreamCreate::stamp which then causes a complaint
from valgrind. This patch sets this value to 0, it's not used
by the client so the value shouldn't matter.
create_test_primary_surface::test_display_base.c creates a
QXLDevSurfaceCreate structure and initialize it, but doesn't set
the position field. Moreover, this structure has 4 bytes of padding
to the end (as shown by pahole from dwarves), so initialize the whole
structure to 0 before using it.
Issue found by the Coverity scanner.
HDG: Fixup don't free RGB24_line if it was not allocated by do_jpeg_encode
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
While discussing various things with Alon in Vancouver, it came up that
having a channel which simply passes through data coming out of a qemu
chardev frontend unmodified, like the usbredir channel does, can be used
for a lot of other cases too. To facilitate this the usbredir channel code
will be turned into a generic spicevmc channel, which is just a passthrough
to the client, from the spicevmc chardev.
This patch renames usbredir.c to spicevmc.c and changes the prefix of all
functions / structs to match. This should make clear that the code is not
usbredir specific.
Some examples of why having a generic spicevmc pass through is good:
1) We could add a monitor channel, allowing access to the qemu monitor from
the spice client, since the monitor is a chardev frontend we could re-use
the generic spicevmc channel server code, so all that is needed to add this
(server side) would be reserving a new channel id for this.
2) We could allow users to come up with new channels of their own, without
requiring qemu or server modification. The idea is to allow doing something
like this on the qemu startup cmdline:
-chardev spicevmc,name=generic,channelid=128
To ensure these new "generic" channels cannot conflict with newly added
official types, they must start at the SPICE_CHANNEL_USER_DEFINED_START value
(128).
These new user defined channels could then either be used with a special
modified client, with client plugins (if we add support for those), or
by exporting them on the client side for use by an external ap, see below.
3) We could also add support to the client to make user-defined channels
end in a unix socket / pipe, allowing handling of the data by an external app,
we could for example have a new spice client cmdline argument like this:
--custom-channel unixsocket=/tmp/mysocket,channelid=128
This would allow for something like:
$random app on guest -> virtio-serial -> spicevmc chardev ->
-> spicevmc channel -> unix socket -> $random app on client
4) On hind sight this could also have been used for the smartcard stuff,
with a 1 channel / reader model, rather then the current multiplexing code
where we've our own multiplexing protocol wrapper over the libcacard
smartcard protocol.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Now that the Channel struct is gone and the RedChannel has the same lifetime
as the chardev interface there is no need to have these 2 separate.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes a valgrind discovered possible bug in spice-server - valgrind on
test_playback saw it, didn't see it happen with qemu.
The problem is that the frames buffers returned by spice_server_playback_get_buffer
are part of the malloc'ed SndChannel, whose lifetime is smaller then that of SndWorker.
As a result a pointer to a previously returned spice_server_playback_get_buffer could
remain and be used after SndChannel has been freed because the client disconnected.
Merging the functionality of reds::channel, into RedChannel.
In addition, cleanup and fix disconnection code: before this patch,
red_dispatcher_disconnect_display_client
could have been called from the red_worker thread
(and it must be called only from the io thread).
RedChannel holds only connected channel clients. RedClient holds all the
channel clients that were created till it is destroyed
(and then it destroys them as well).
Note: snd_channel still doesn't use red_channel, however it
creates dummy channel and channel clients, in order to register itself
in reds.
server/red_channel.c: a channel is connected if it holds at least one channel client
Previously I changed RedChannel to hold only connected channel clients and
RedClient, to hold all the channel clients as long as it is not destroyed.
usbredir: multichannel has not been tested, it just compiles.
client_cbs are supposed to be called from client context (reds). This patch will be used
in future patches for relacing reds::Channel with RedChannel in order to eliminate redundancy.
introduces ref_red_drawable and put_red_drawable (rename from free_red_drawable)
RedDrawable is already references by Drawable and RedGlzDrawable, with
a hack to NULL the drawable field in RedGlzDrawable to indicate RedGlzDrawable
is the last reference holder. Using an explicit reference count instead.
CursorPipeItems and their corresponding cursor_item were not
freed when they were removed from the pipe without sending them.
In addition cursor_channel_hold_pipe_item used wrong conversion
to (CursorItem*) for a (CursorPipeItem*).
Required to support multiple clients.
Also changes somewhat the way we produce PIPE_ITEM_TYPE_LOCAL_CURSOR. Btw,
I haven't managed to see when we actually produce such an item during my
tests.
Previously we had a single pipe item per CursorItem, this is impossible
with two pipes, which happens when we have two clients.
Also adds Drawable pipes and glz rings.
main_channel and red_worker had several locations that still accessed rcc
directly, so they had to be touched too, but the changes are minimal.
Most changes are in red_channel: drop the single client reference in RedChannel
and add a ring of channels.
Things missing / not done right in red_worker:
* StreamAgents are in DCC - right/wrong?
* GlzDict is multiplied - multiple compressions.
We still are missing:
* remove the disconnect calls on new connections
There is no inter-client shared dictionary and cache yet.
At this point the display channel can be used by multiple clients.
You can still crash on lack of Drawables or CursorItems due to the slower
clients pipe growing uncontrollably.
This patch compiles but breaks spice.
Split both display and cursor channels to a client part and channel part.
Introduce DisplayChannelClient, CursorChannelClient, CommonChannelClient.
don't disconnect channel on client disconnect.
Move all caches to the ChannelClient's.
Remove reference counting of the channel.
No new functionality introduced.
NOTE: Introduces a crash in disconnections, a regression, resulting from
incorrect thread access, that is fixed in the patch titled:
"server: registering RedChannel in reds, instead of Channel"
each client supplying a smartcard channel gets it's own smartcard. If
there are not enough smartcards provided by the server (read: qemu)
then it will be as though there are none.
currently disabled - later patches that enable smartcard don't make
this channel available to any but the first client.
s/TunnelChannel/TunnelChannelClient/
That's about it. this is probably the wrong way to do it. Not tested
at all. What do we want, a separate interface per client? same interface
for all clients? probably the later. This doesn't do that. Not tested,
so probably doesn't even work.
changes red_channel_pipe_item_is_linked to red_channel_client_pipe_item_is_linked,
since tunnel channel is the only user, must be done in patch to not break compilation.
The main channel deals with connecting new clients, announcing mouse mode
changes, and the agent channel. The implementation is currently done without
any changes to the protocol, so everything has to be either broadcast or
to a specific client.
channels list - specific client
mouse mode - broadcast
agent - broadcast
notify - broadcast (should have two modes, and use the appropriate)
Notable TODOs:
* migration testing
* agent tokens are wrongly sent (or did I fix that? check)
Introduce functions to add (via producer method) the same item to multiple
pipes, all for the same channel.
Note: Right now there is only a single channel, but the next patches will do the
per-channel breakdown to channel and channel_client before actually introducing
a ring in RedChannel, this makes it easier to make smaller changes - the
channel->rcc link will exist until removed in the ring introducing patch.
on red_channel_peer_on_incoming_error, if we are already shutdown, do not
call the channel's error handler. Since the channel has been shutdown, we
assume this is a second or later error, and handling has already occured.
Expose additional api to find a client given a connection_id. The connection_id
is first set when the first channel connects, which is the main channel.
It could also be kept in the RedClient instead, not sure.
TODO:
multiple todo's added for multiclient handling. I don't remember why
I wrote them exactly, and besides if I did any migration tests. So: TODO.
cleanup only. Note that the ping function is half used since the opt parameter
stopped being called with anything but NULL, should be returned at some point,
specifically when we drop the 250kbyte ping on start and do a continuous check
for latency and bandwidth.
See:
81945d897 - server: add new vd interface QTerm2Interface, Yaniv Kamay
introducing the usage of ping with a non NULL opt
3f7ea8e7a - zap qterm interfaces, Gerd Hoffman
removing it
They were globals before. This introduces api for other channels
to query the low bandwidth status. The queries themselves are still done
from the wrong context (channel and not channel client) but that's because
the decoupling of channel and channel client will be done in the following
patches.
Note that snd_worker.c got two copied function declarations that belong to
main_channel.h but can't be easily dragged into snd_worker.c since it still
uses it's own RedChannel struct.
Secondary channels are those that don't support multiple clients. The
support added in this patch just doesn't let the second or more connected
client receive the unsupported channels in the channels list sent by the
server to the client. This doesn't handle the situation where:
client A connects (gets all channels)
client B connects (gets supported multiple client channels)
client A disconnects (Suboptimal 1: B doesn't get new channels at this point)
client C connects (Suboptimal 2: C doesn't get the full list of channels, but
the partial one)
Specifically the channels that only support a single client are:
sound (both playback and record channels)
smartcard
tunnel
That means RedClient tracks a ring of channels. Right now there will be only
a single client because of the disconnection mechanism - whenever a new
client comes we disconnect all existing clients. But this patch adds already
a ring of clients to reds.c (stored in RedServer).
There is a known problem handling many connections and disconnections at the
same time, trigerrable easily by the following script:
export NEW_DISPLAY=:3.0
Xephyr $NEW_DISPLAY -noreset &
for ((i = 0 ; i < 5; ++i)); do
for ((j = 0 ; j < 10; ++j)); do
DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests &
done
sleep 2;
done
I fixed a few of the problems resulting from this in the same patch. This
required already introducing a few other changes:
* make sure all removal of channels happens in the main thread, for that
two additional dispatcher calls are added to remove a specific channel
client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and
RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT).
* change some asserts in input channel.
* make main channel disconnect not recursive
* introduce disconnect call back to red_channel_create_parser
The remaining abort is from a double free in the main channel, still can't
find it (doesn't happen when running under valgrind - probably due to the
slowness resulting from that), but is easy to see when running under gdb.
use MainChannel* instead of Channel* for a many functions in main_channel.h
(affects main_channel.c and reds.c).
some one liner fixes are hidden in here too.
Another cleanup patch, no change to behavior (still one client, and it
disconnects previous client if any).
The implementation for multiple client is straightforward: the pipe
remains per (channel,client) pair, so it needs to move from the RedChannel
that to RedChannelClient. Implementation using a single pipe with multiple
consumers (to reflect different latencies) doesn't fit well with pipe rewriting
that is used by the display channel. Additionally this approach is much simpler
to verify. Lastly it doesn't add considerable overhead (but see the display
channel changes in a later patch for a real place to rethink).
This patch is just technical, changing signatures to reflect the first
argument (oop style) so red_channel becomes red_channel_client. Some places
may seem odd but they should be fixed with later comits where the channels
grow to support multiple clients.
Sound (playback/record) channels are the only ones not touched - this is
consistent with previous patches, since they have been left out of the
RedChannel refactoring. That is left as future work. (note that they don't use
a pipe, which was the reason for not refactoring).
