> > Hi, > > On Fri, 2017-06-02 at 11:31 -0400, Frediano Ziglio wrote: > > > > > > Inform client that transfer will not work, instead of only > > > dropping the agent messages. > > > > > > The file transfer messages can be disabled using qemu cli option: > > > "disable-agent-file-xfer" > > > > > > Resolves: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1373725 > > > > > > Signed-off-by: Pavel Grunt <pgrunt@xxxxxxxxxx> > > > --- > > > server/reds.c | 34 ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 34 insertions(+) > > > > > > diff --git a/server/reds.c b/server/reds.c > > > index bafd04bab..fd163250d 100644 > > > --- a/server/reds.c > > > +++ b/server/reds.c > > > @@ -1111,6 +1111,39 @@ static void > > > reds_on_main_agent_monitors_config(RedsState *reds, > > > reds_client_monitors_config_cleanup(reds); > > > } > > > > > > +static void agent_data_free(uint8_t *data, G_GNUC_UNUSED void > > > *opaque) > > > +{ > > > + free(data); > > > +} > > > + > > > +/* > > > + * Inform client about discarded file transfer > > > + * https://bugzilla.redhat.com/show_bug.cgi?id=1373725 > > > + */ > > > +static void agent_xfer_error(MainChannelClient *mcc, const > > > VDAgentMessage > > > *message) > > > +{ > > > + VDAgentMessage *xfer_msg; > > > + VDAgentFileXferStatusMessage *xfer_status; > > > + size_t len; > > > + > > > + if (message->type < VD_AGENT_FILE_XFER_START || message->type > > > > > > > VD_AGENT_FILE_XFER_DATA) { > > > + return; > > > + } > > > + > > > + len = sizeof(VDAgentMessage) + > > > sizeof(VDAgentFileXferStatusMessage); > > > + xfer_msg = spice_malloc0(len); > > > + xfer_msg->protocol = VD_AGENT_PROTOCOL; > > > + xfer_msg->type = VD_AGENT_FILE_XFER_STATUS; > > > + xfer_msg->size = sizeof(VDAgentFileXferStatusMessage); > > > + xfer_status = (VDAgentFileXferStatusMessage *) xfer_msg- > > > >data; > > > + xfer_status->id = ((VDAgentFileXferStartMessage *) message- > > > >data)->id; > > > > VDAgentFileXferStartMessage should be const but the real problem is > > this: > > > > reds.c: In function 'agent_xfer_error': > > reds.c:1139:5: error: dereferencing type-punned pointer will break > > strict-aliasing rules [-Werror=strict-aliasing] > > xfer_status->id = ((VDAgentFileXferStartMessage *) message- > > >data)->id; > > > > ^~~~~~~~~~~ > > > Do you have a clue why I don't get the warning? > > my CFLAGS are: > -Wall -Wextra -g -Wstrict-aliasing > > gcc-7.1.1-1.fc26.x86_64 > clang-4.0.0-3.fc26.x86_64 > > Thanks, > Pavel > Mine is gcc-6.3.1-1.fc25.x86_64 (Fedora 25). No idea, as far as I know there should be no alias but maybe the tracking of 6.3 is not enough to detect it. Note that using uint32_t instead of VDAgentFileXferStartMessage have the same issue. xfer_status->id = ((const VDAgentFileXferStartMessage *) (message+1))->id; works for me. A bit less readable but not that much. Frediano > > no idea... but if I write (message+1) instead of message->data > > (which is from ABI the same) > > the warning disappears :-( Not counting that data is uint8_t, a type > > that is supposed to > > be ok to be aliases... but maybe I didn't understand something about > > aliasing. > > Also spice_malloc0 is marked as __attribute__((malloc)) which should > > tell compiler > > that xfer_msg (and so xfer_status) cannot alias... > > > > > + xfer_status->result = VD_AGENT_FILE_XFER_STATUS_ERROR; > > > + > > > + spice_debug("canceling file transfer %u", xfer_status->id); > > > + > > > + main_channel_client_push_agent_data(mcc, (uint8_t *) > > > xfer_msg, len, > > > agent_data_free, NULL); > > > +} > > > + > > > void reds_on_main_agent_data(RedsState *reds, MainChannelClient > > > *mcc, const > > > void *message, > > > size_t size) > > > { > > > @@ -1124,6 +1157,7 @@ void reds_on_main_agent_data(RedsState > > > *reds, > > > MainChannelClient *mcc, const void > > > case AGENT_MSG_FILTER_OK: > > > break; > > > case AGENT_MSG_FILTER_DISCARD: > > > + agent_xfer_error(mcc, message); > > > return; > > > case AGENT_MSG_FILTER_MONITORS_CONFIG: > > > reds_on_main_agent_monitors_config(reds, mcc, message, > > > size); > > > > Frediano > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel