MainChannelClient is used by other clients to store some data
so should not disappear if other clients are still present.
Keep a owning reference to it and release after RedClient is
released.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Disconnecting a single channel from the client caused the server to
keep a stale channel client (RedChannelClient object) till the client
(RedClient object) entirely disconnected, that is the channel client
is disconnected but still in the list preventing new connections.
Calling red_client_remove_channel from red_channel_client_disconnect
fixes this last issue.
An issue was that was not clear how the ownership were managed. When
red_client_destroy was called red_channel_client_destroy was called
which freed the RedChannelClient object so this should imply
ownership.
However same red_channel_client_destroy call was attempted by
RedChannel using its list (red_channel_destroy). Basically the two
pointers (the one from the channel and the one from the client) were
considered as one ownership. To avoid the confusion now the client
list always decrement the counter.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The channels list was not protected by a lock in red_client_destroy.
This could cause for instance a RedChannelClient object to be
created while scanning the list so potentially modifying the
list while scanning with all race issues.
Consider a client which attempt to connect to a new channel and
then for some reason close the main channel:
- the new channel connection is handled by the main thread;
- the relative RCC will be passed to red_channel_connect which
can decide to continue the initialization in another thread
(this happens currently for CursorChannelClient and
DisplayChannelClient);
- the main thread will catch the main channel disconnection and
call main_dispatcher_client_disconnect
(from main_channel_client_on_disconnect);
- main thread calls reds_client_disconnect;
- reds_client_disconnect calls red_client_destroy;
- now we have 2 thread which will attempt to change RedClient::channels
list, one protected by the mutex the other not.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Create some traffic on the connection to avoid potential timeout
on some proxies implementation which require some TCP data traffic.
The timeout used by default is quite big (5 minutes) to reduce network
traffic.
In case connectivity monitoring is enabled or latency monitor is
requested the timeout is reduced to the old default.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This is a preparatory patch.
The "latency_monitor" feature allows to measure the latency of a
specific channel client.
Currently the measure is attempted every PING_TEST_TIMEOUT_MS which
is a constant.
To be able to use a different frequency allows to change this for every
channel client.
This feature will be also used to create some traffic on the connection
to allows some sort of keep-alive to overcome some proxy implementation
which requires some TCP data traffic.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1719736.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
"&rcc->priv->connectivity_monitor" is cached in "monitor" variable.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
These functions already check for NULL.
They are used mainly for cleanup, so cold path of code so speed
in case of NULL is not important (and usually should not be NULL).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
For some reason under Fedora 31 the g_socket_client_connect call
from test-listen test caused Valgrind to detect a leak.
Note that the like at gtype.c (g_socket_client_connect) specifically
marks a memory block as malloc-like. Not sure if it's an issue
with Valgrind or with GLib, as a workaround disable the leak report.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This suppression was present in former glib.supp version however
the suppression in glib.supp was updated to only catch "reachable"
leaks.
However in test-listen test the allocation is done in a thread
causing the leak to become "definite".
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
OpenGL and Slirp requirement were removed much time ago.
OpenGL was removed by c5c176a5c7
(cfr "server: remove OpenGL", Set 2013).
Slirp was removed by ef9a8bf053
(cfr "Remove tunneling support", Oct 2013).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The threading API for 1.0 was replaced with the THREADID API.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Missing headers for BN_ and RSA_ functions.
Initialization is deprecated with 1.1.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Allow to modify/cancel timers/watches without having to retrieve
the code interface.
This will make sure that you are not using the wrong interface.
Simplify code to deal with timers/watches.
Remove the requirement to have the core interface available
for removing timers/watches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Put more event loop code in event-loop.c.
This is a preparation patch for the next one.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The buffer could change inside smartcard_read_buf_prepare.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Using coverage utility exercise more code paths:
- message from channel with wrong type;
- remove message from channel with already removed reader;
- init message from channel (ignored);
- data from devices, ADPU;
- error from device;
- messages split in different ways;
- invalid reader_id values.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Create Smardcard device.
Connect to it and test some messages are parsed and processed
as expected.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Allows to reuse code for emulating a character device.
It will be used for Smardcard test.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This patch handles the scenario when a single read to guest device
brings multiple requests to be handled. When this happens, we will
iterate till all requests are handled and no more requests can be read
from guest device.
If the remaining buffer contains a full request we don't need to read
other bytes (note that there could be no bytes left), just parse the
request.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Use memmove instead of memcpy as the buffer can overlap if the second
request if bigger than the first.
"buf_pos" points to the point of the buffer after we read, if we want
the first part of the next request is "buf_pos - remaining".
Same consideration setting "buf_pos" for the next iteration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Avoid client to trigger crash. The value of smartcard_readers_get
is checked for NULL so returning it it's not an issue.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
More coherent. Also it's not good for a library to output on
standard output.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
red_channel_client_handle_message is called after parsing the
message so it's not necessary to check it again or parse manually.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
As base messages require parsing better channels should always use
the generated parser.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The generated code handle possible endianess mismatch and check
for message format.
The copy back to "write_buf" allows to use that buffer to send
data back to device.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
"name" parameter of smartcard_channel_client_add_reader it's not
used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
"self-tokens" property is 64 bit and must be passed as 64 bit on
32 bit machines to avoid memory corruptions.
This was introduced by 01de3b8922 ("spicevmc: Avoids DoS if
guest device is not able to get data faster enough"), detected by CI.
It caused this error (split into multiple lines):
(./test-leaks:15879): GLib-GObject-CRITICAL **: 14:03:59.650: \
g_object_new_is_valid_property: object class 'RedCharDeviceSpiceVmc' has \
no property named '\xb0/@\xf3\u0001'
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This fix half (one direction) of
https://gitlab.freedesktop.org/spice/spice/issues/29.
Specifically if you have attempt to transfer a file from the client
using WebDAV.
Previously the queue to the device was unbound. If device was not
getting data fast enough the server started queuing data.
To easily test this you can suspend the WebDAV daemon while transferring
a big file from the client.
To simplify the code and reduce the changes server buffers are
used. This as client token implementation is written with agent
in mind. While when we exhaust server tokens RedCharDevice doesn't
close the client when we exhaust client tokens RedCharDevice closes
the client which in this case it's not wanted.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
If the client is keeping sending data while we can't handle them
(for instance because we need to forward to a device but the
device is not fast enough to receive that amount of data) allows
to stop RedChannelClient to read data.
This after a bit will stop the client sending data as its output
buffer will become full.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This fix half (one direction) of
https://gitlab.freedesktop.org/spice/spice/issues/29.
Specifically if you have attempt to transfer a file to the client
using WebDAV.
Previously the queue to the client was unbound. If client was not
getting data fast enough the server started queuing data.
To easily test this you can use a tool to limit bandwidth and
transfer a big file (I used a "dd if=/dev/zero bs=1M of=test") from
the guest.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
As we don't use any token there's no reason to not queue directly instead
of passing through RedCharDevice.
This will make easier to limit the queue which currently is unlimited.
RedCharDevice flow control has some problems:
- it's really designed with VDI in mind. This for SpiceVMC would cause
code implementation to be confusing having to satisfy the agent token
handling;
- it's using items as unit not allowing counting bytes;
- it duplicates some queue management between RedChannelClient;
- it's broken (see comments in char-device.h);
- it forces "clients" to behave in some way not altering for instance the
queued items (which is very useful if items can be collapsed together);
- it replicates the token handling on the device queue too. This could
seems right but is not that if you have a network card going @ 1 GBit/s
you are able to upload more than 1 Gbit/s just using multiple
connections. The kernel will use a single queue for the network interface
limiting and sharing de facto the various buffers between the multiple
connections.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
It does not make sense to have a graphic card without a monitor.
In spice_qxl_set_max_monitors we prevent to set 0 monitors, do
the same in spice_qxl_set_device_info.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1691721.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
As now is an opaque type for RedCharDevice use the type that
better suits us.
This avoid useless conversions or look ups.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
RedClient was an opaque structure for RedCharDevice.
It started to be used when RedsState started to contain all
the global state.
Make it opaque again using a new RedCharDeviceClientOpaque.
The RedCharDeviceClientOpaque define in the header allows users
of the class to override the type to get a more safe type
than RedClient.
The define at the beginning of C file is to make sure we don't
use the opaque type as a specific one.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
No much reason for not inlining it, it's quite small and do
not reduce readability.
Note that spice_server_migrate_switch is deprecated and not
used by Qemu since commit 67be6726b6459472103ee87ceaf2e8e97c154965
(cfr "spice: raise requirement to 0.12" September 2012).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
