summaryrefslogtreecommitdiffstats
path: root/server/red_channel.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix test_capability() typoChristophe Fergeau2014-03-131-7/+7
| | | | It was spelt 'capabilty'
* Add reds_stream.[ch]Christophe Fergeau2014-01-201-0/+1
| | | | | Gather common RedsStream code there rather than having it in reds.c
* Silence gcc false positive with -WuninitializedChristophe Fergeau2013-10-281-0/+6
| | | | | | | | | | | | | | | | | Some versions of gcc warn about: red_channel.c: In function 'red_channel_client_wait_outgoing_item': red_channel.c:2331: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] red_channel.c: In function 'red_channel_client_wait_pipe_item_sent': red_channel.c:2363: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] red_channel.c: In function 'red_channel_wait_all_sent': red_channel.c:2401: error: 'end_time' may be used uninitialized in this function [-Wuninitialized] This is a false positive as end_time is unitialized when timeout is -1, and we will only try to use end_time if timeout is not -1. This commit initializes end_time to UINT64_MAX to avoid that warning. As the test involving end_time will never be reached, we ensure it's always TRUE so that it would be a noop even if it was reached.
* red_channel: cleanup of red_channel_client blocking methodsYonit Halperin2013-09-261-37/+36
| | | | | | (1) receive timeout as a parameter. (2) add a return value and pass the handling of failures to the calling routine.
* red_channel: add option to monitor whether a channel client is aliveYonit Halperin2013-08-141-0/+119
| | | | | | | | | | rhbz#994175 When a client connection is closed surprisingly (i.e., without a FIN segment), we cannot identify it by a socket error (which is the only way by which we identified disconnections so far). This patch allows a channel client to periodically check the state of the connection and identify surprise disconnections.
* red_channel: add on_input callback for tracing incoming bytesYonit Halperin2013-08-141-0/+7
| | | | The callback will be used in the next patch.
* server: s/red_wait_all_sent/red_channel_wait_all_sent/Alon Levy2013-08-141-1/+1
|
* server: move three functions to red_channelAlon Levy2013-08-141-0/+106
| | | | | | | | | | | | | | | Three blocking functions, one was split to leave the display channel specific referencing of the DrawablePipeItem being sent inside red_worker, but the rest (most) of the timeout logic was moved to red_channel, including the associated constants. Moved functions: red_channel_client_wait_pipe_item_sent red_wait_outgoing_item red_wait_all_sent Introduces red_time.h & red_time.c for a small helper function dealing with time.h
* log: improve debug information related to client disconnectionYonit Halperin2013-07-291-3/+6
|
* red_channel: add ref count to RedClientYonit Halperin2013-07-291-3/+20
|
* red_channel: prevent adding and pushing pipe items after a channel_client ↵Yonit Halperin2013-07-291-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | has diconnected Fixes: leaks of pipe items & "red_client_destroy: assertion `rcc->send_data.size == 0'" red_channel_disconnect clears the pipe. It is called only once. After, it was called, not items should be added to the pipe. An example of when this assert can occur: on_new_cursor_channel (red_worker.c), pushes 2 pipe items. When it pushes the first pipe item, if the client has disconnected, it can hit a socket error, and then, red_channel_client_disconnect is called. The second call to adding a pipe item, will add the item to the pipe. red_channel_client_pipe_add_type also calls red_channel_client_push, which will update the send_data.size. Then, the push will also hit a socket error, but red_channel_client_disconnect won't clear the pending pipe item again, since it was already called. When red_client_destory is called, we hit assertion `rcc->send_data.size == 0'. Note that if a pipe item is added to the pipe after red_channel_client_disconnect was called, but without pushing it, we should hit "spice_assert(rcc->pipe_size == 0)".
* server/red_channel: fix unused variableAlon Levy2013-07-281-10/+13
| | | | unused variable 'so_unsent_size' [-Werror=unused-variable]
* TIOCOUTQ -> SIOCOUTQ and portability ifdefsNahum Shalman2013-07-221-2/+11
| | | | | | | | The ioctl on sockets is actually named SIOCOUTQ though its value is identical to TIOCOUTQ which is for terminals. SIOCOUTQ is linux specific so we add a header check and ifdef based on the presence of the header This prevents bogus ioctls on non-Linux platforms
* red_channel: replace RING_FOREACH with RING_FOREACH_SAFE in some placesUri Lublin2013-07-161-4/+4
| | | | | | | | This was originally intended to fix the problem fixed by commit 53488f0275d6c8a121af49f7ac817d09ce68090d. What is left are FOREACH loops that are at less risk and maybe safe (no read/write or disconnect/destroy are called from within them).
* Use RING_FOREACH_SAFE in red_channel.c functions which are missing itDavid Gibson2013-07-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, both red_channel_pipes_add_type() and red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not safe versus removals from the ring within the loop body. Although it's rare, such a removal can occur in both cases. In the case of red_channel_pipes_add_type() we have: red_channel_pipes_add_type() -> red_channel_client_pipe_add_type() -> red_channel_client_push() And in the case of red_channel_client_pipes_add_empty_msg() we have: red_channel_client_pipes_add_empty_msg() -> red_channel_client_pipe_add_empty_msg() -> red_channel_client_push() But red_channel_client_push() can cause a removal from the clients ring if a network error occurs: red_channel_client_push() -> red_channel_client_send() -> red_peer_handle_outgoing() -> handler->cb->on_error callback = red_channel_client_default_peer_on_error() -> red_channel_client_disconnect() -> red_channel_remove_client() -> ring_remove() When this error path does occur, the assertion in RING_FOREACH()'s ring_next() trips, and the process containing the spice server is aborted. i.e. your whole VM dies, as a result of an unfortunately timed network error on the spice channel. Please apply. Signed-off-by: David Gibson <dgibson@redhat.com>
* spice: silencing most of the ping/pong loggingYonit Halperin2013-06-241-11/+2
| | | | Those messages are too frequent and don't contribute much
* red_channel: replace an assert upon threads mismatch with a warningYonit Halperin2013-05-241-3/+25
| | | | | | | | | | | | | | | | | | | | | | | The assert: spice_assert(pthread_equal(pthread_self(), client->thread_id)) and the assert: spice_assert(pthread_equal(pthread_self(), rcc->channel->thread_id)) were coded in order to protect data that is accessed from the main context (red_client and most of the channels), from access by threads of other channels (namely, the display and cursor channels), and vice versa. However, some of the calls to the sound channel interface, and also the char_device interface, can be done from the vcpu thread. It doesn't endanger these channels internal data, since qemu use global mutex for the vcpu and io threads. Thus, pthread_self() can be != channel->thread_id, if one of them is the vcpu thread and the other is the io-thread, and we shouldn't assert. Future plans: A more complete and complicated solution would be to manage our own thread for spice-channels, and push input from qemu to this thread, instead of counting on the global mutex of qemu rhbz#823472
* red_channel: notify and shutdown a channel client when its ↵Yonit Halperin2013-05-081-2/+5
| | | | handle_migrate_data fails
* red_channel: on migration target, start sending ping messages only after the ↵Yonit Halperin2013-05-011-1/+15
| | | | | | | | | | client's migration has completed The connection to the target server is established before migration starts. However, the client reads and replies to messages from the server only after migration completes. Thus, we better not send ping msgs from the target before migration completes (because the observed roundtrip duration will be bigger than the real one).
* red_channel: stop sending ping messages after migration has completedYonit Halperin2013-05-011-0/+5
| | | | | We mustn't send any msg to the client, besides MSG_MIGRATE_DATA, after we send MSG_MIGRATE.
* red_channel: fix not handling self pipe items in red_channel_client_release_itemYonit Halperin2013-04-301-0/+3
| | | | | | | When a client disconnects, red_channel_client_pipe_clear is called. Releasing pipe items of type == MIGRATE||EMPTY_MSG||PING wasn't handled, and was passed to channel_cbs.release_item. There, an error occured since the pipe items were not recognized.
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-221-0/+228
|
* server: freezed->froze, missing whitespace after declarationsAlon Levy2012-08-301-0/+1
|
* red_channel: set send_data.last_sent_serial in ↵Yonit Halperin2012-08-271-0/+1
| | | | | | | | red_channel_client_set_message_serial red_channel_client_set_message_serial is called for setting the serial of the display channel messages after migration (on the destination side). The serial is retrieved from the migration data.
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-4/+3
| | | | The relevant flags reside in RedChannelClient and RedClient
* red_channel (dummy): fix not adding dummy RedChannelClient to the clientYonit Halperin2012-08-271-11/+23
| | | | | | | | | | | snd channel wasn't added to be part of the client's channels list. As a result, when the client was destroyed, or migrated, snd channel client wasn't destroy, or its migration callback wasn't called. However, due to adding dummy channels to the client, we need special handling for calls to disconnecting dummy channel clients. TODO: we need to refactor snd_worker to use red_channel
* main: send MSG_MIGRATE upon vm migration completionYonit Halperin2012-08-271-1/+1
| | | | | | | | | Before sending the above msg, if there is a pending partial msg that has been read from the agent, we send it to the client. The alternative was to keep the msg as part of the migration data, and then to send it to the destination server via the client and to wait there for the msg chunk completion, before sending it to the client. Of course, the latter is less efficient.
* red_channel: introduce PIPE_ITEM_TYPE_EMPTY_MSGYonit Halperin2012-08-271-0/+39
| | | | The pipe item is used for sending messages that don't have body.
* seamless migration: migration completion on the destination sideYonit Halperin2012-08-271-9/+98
| | | | | | Tracking the channels that wait for migration data. If there is a new migration process pending, when all the channels have restored their state, we begin the new migration.
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-4/+34
| | | | | | | The relevant code is common to all channels. The patch also contains a fix to the return value for handle_migrate_data callback: s/uint64_t/int
* red_channel: fix pipe item leakYonit Halperin2012-08-271-0/+1
|
* red_channel: add red_channel_test_remote_capYonit Halperin2012-08-271-0/+28
| | | | for checking if all the channel clients connected support the cap
* server/red_channel: s/channle/channelAlon Levy2012-06-071-3/+3
|
* server/red_channel: do not attempt to write if the channel client is ↵Yonit Halperin2012-05-311-0/+4
| | | | | | | | | disconnected The red_channel_client_event call to red_channel_client_receive might result in a disconnected channel client. The following call to red_channel_client_push may call to red_peer_handle_outgoing with a disconnected socket.
* server/red_channel: fix possible access to released channel clientsYonit Halperin2012-05-311-20/+99
| | | | | | | | | | | | | Added ref count for RedChannel and RedChannelClient. red_channel.c/red_peer_handle_incoming call to handler->cb->handle_message might lead to the release of the channel client, and the following call to handler->cb->release_msg_buf will be a violation. This bug can be produced by causing main_channel_handle_parsed call red_client_destory, e.g., by some violation in reds_on_main_agent_data that will result in a call to reds_disconnect.
* server/red_channel: remove red_channel_client_item_being_sentYonit Halperin2012-05-241-19/+0
| | | | | | The above routine was risky, since red_channel_client_init_send_data can also be called with item==NULL. Thus, not all pipe items can be tracked. The one call that was made for this routine was not necessary.
* server/red_channel: prevent creating more than one channel client with the ↵Yonit Halperin2012-05-211-4/+46
| | | | same type+id
* Use the spice-common logging functionsMarc-André Lureau2012-03-251-48/+48
| | | | | It will abort by default for critical level messages. That behaviour can be tuned at runtime.
* Use the spice-common submoduleMarc-André Lureau2012-03-251-2/+4
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* red_channel: remove pre_disconnect hookHans de Goede2012-03-121-3/+0
| | | | | | Now that red_worker's EventListener is gone there are no more users of it. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_channel: Use the channel core to remove the stream watch on disconnectHans de Goede2012-03-121-0/+4
| | | | | | | | | | | | | | | | | 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>
* Ensure all members of ChannelCbs and ClientCbs are either assigned or NULLHans de Goede2012-03-101-2/+2
| | | | | | | | | | | | | | | While git-bisecting another issue I ended up hitting and not recognizing the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb. 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>
* Use standard IOV_MAX definition where applicableDan McGee2012-02-211-1/+1
| | | | | | | | 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>
* red_worker: reimplement event loop using poll()Dan McGee2012-02-211-0/+3
| | | | | | | | | | | | | | | | | | 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>
* Use memcpy call in red_channel_createDan McGee2012-02-211-8/+1
| | | | | | | | | 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>
* Cleanup definitions of disconnect methodsDan McGee2012-02-211-2/+0
| | | | | | | | | 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>
* server/spicevmc: Don't destroy the rcc twiceHans de Goede2012-02-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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 ffc4de01e6f9ea0676f17b10e45a137d7e15d6ac 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>
* server/red_channel: red_peer_handle_incoming: comment on null checkAlon Levy2012-01-231-0/+2
| | | | Signed-off-by: Alon Levy <alevy@redhat.com>
* server/red_channel: avoid segfault if stream == NULLAlon Levy2012-01-221-0/+4
|
* server: add support for SPICE_COMMON_CAP_MINI_HEADERYonit Halperin2012-01-121-55/+164
| | | | | | | | | 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.
generated by cgit (git 2.34.1) at 2024-06-08 13:31:12 +0000