Signed-off-by: Frediano Ziglio
---
src/spice-widget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/spice-widget.c b/src/spice-widget.c
index 312c640a..9bb42211 100644
--- a/src/spice-widget.c
+++ b/src/spice-widget.c
@@ -2994,8 +2994,6 @@ static void channel_new(SpiceSession *s, Spice
> On 29 Nov 2018, at 18:23, Frediano Ziglio wrote:
>
>> Hey,
>>
>> On Thu, Nov 29, 2018 at 08:50:47AM -0500, Frediano Ziglio wrote:
On Wed, Nov 28, 2018 at 11:23:17AM +0100, Christophe de Dinechin wrote:
>> On 27 Nov 2018, at 15:38, Christophe Fergeau
>> wrote:
>> I'm n
> Hey,
>
> On Thu, Nov 29, 2018 at 08:50:47AM -0500, Frediano Ziglio wrote:
> > >
> > > On Wed, Nov 28, 2018 at 11:23:17AM +0100, Christophe de Dinechin wrote:
> > > > > On 27 Nov 2018, at 15:38, Christophe Fergeau
> > > > > wrote:
> > > > > I'm not really asking how to use it, but it's very odd
For the series,
Acked-by: Christophe Fergeau
On Thu, Nov 29, 2018 at 07:51:53AM +, Frediano Ziglio wrote:
> Avoid in some situations an malicious server to led to some minor
> reading buffer overflows. These overflows cannot cause code execution
> or information leakage.
>
> Frediano Ziglio
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20181126153036.22414-1-fzig...@redhat.com
Subject: [Qemu-devel] [PATCH] spice: Use new SpiceImageCompression definition
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
t
Hey,
On Thu, Nov 29, 2018 at 08:50:47AM -0500, Frediano Ziglio wrote:
> >
> > On Wed, Nov 28, 2018 at 11:23:17AM +0100, Christophe de Dinechin wrote:
> > > > On 27 Nov 2018, at 15:38, Christophe Fergeau
> > > > wrote:
> > > > I'm not really asking how to use it, but it's very odd to have a patc
>
> On Wed, Nov 28, 2018 at 11:23:17AM +0100, Christophe de Dinechin wrote:
> > > On 27 Nov 2018, at 15:38, Christophe Fergeau wrote:
> > > I'm not really asking how to use it, but it's very odd to have a patch
> > > adding a new dep without seeing any accompanying patches which need that
> > > d
At the moment, we'll unconditionally release the guest QXL resources in
red_put_drawable() even if red_get_drawable() failed and did not
initialize drawable->release_info_ext properly.
This commit only sets RedDrawable::qxl once the guest resource have been
successfully retrieved, and only free the
---
server/red-parse-qxl.c | 11 +++
server/red-parse-qxl.h | 3 ++-
server/red-worker.c| 3 +--
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
index e88e75096..1608caff2 100644
--- a/server/red-parse-qxl.c
+++ b/server
---
server/red-parse-qxl.c | 7 +--
server/red-parse-qxl.h | 3 ++-
server/red-worker.c| 3 +--
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
index 7e6f5ce9d..4be53d3e5 100644
--- a/server/red-parse-qxl.c
+++ b/server/red-par
RedDrawable really is a RedDrawCmd which is parsed by red-parse-qxl.h
Moreover, red_drawable_ref() is already defined inline in
red-parse-qxl.h, and red_drawable_unref() is declared there too even if
its code is still in red-worker.c
This commit moves them close to the other functions creating/unre
Currently, RedMessage are allocated on the stack, and then
initialized/uninitialized with red_{get,put}_message
This makes the API inconsistent with what is being done for RedDrawable
and RedCursor. Since QXLMessage is just a (mostly unused/unsecure) debugging
tool,
we can dynamically allocate it
Currently, RedUpdateCmd are allocated on the stack, and then
initialized/uninitialized with red_{get,put}_update_cmd
This makes the API inconsistent with what is being done for RedDrawable,
RedCursor and RedMessage. QXLUpdateCmd are not occurring very often,
we can dynamically allocate them instead
---
server/display-channel.c | 3 ---
server/red-parse-qxl.c | 12
server/red-parse-qxl.h | 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/server/display-channel.c b/server/display-channel.c
index 91ef72215..e68ed10f8 100644
--- a/server/display-channel.c
++
Now that we have a refcounted RedSurfaceCmd, we can store the command
itself in DisplayChannel rather than copying QXLReleaseInfoExt. This
will let us move the release of the QXL guest resources in red-parse-qxl
in the next commit.
---
server/display-channel-private.h | 7 ++-
server/display-
Currently, RedWorker is using stack-allocated variables for RedSurfaceCmd.
Surface commands are rare enough that we can dynamically allocate them
instead, and make the API in red-parse-qxl.h consistent with how other
QXL commands are handled.
---
server/red-parse-qxl.c | 38 ++
Rather than needing to call red_drawable_new() and then initialize it
with red_get_drawable(), we can improve slightly red_drawable new so
that red_drawable_{new,ref,unref} is all which is used by code out of
red-parse-qxl.c.
---
server/red-parse-qxl.c | 17 -
server/red-parse-qxl.
Currently, the cursor channel is allocating RedCursorCmd instances itself, and
then
calling into red-parse-qxl.h to initialize it, and doing something
similar when releasing the data. This commit moves this common code to
red-parse-qxl.[ch]
The ref/unref are not strictly needed, red_cursor_cmd_fre
Hey,
Currently, after parsing a QXL command through red-parse-qxl, the code which
got the command has to tell red-parse-qxl when it no longer needs the
command, but also to remember to release the command QXL resources
itself. This series moves this 'release resource' logic to
red-parse-qxl. This
19 matches
Mail list logo
