- 03 Aug, 2015 40 commits
-
-
Colin Ian King authored
commit ca4da5dd upstream. __key_link_end is not freeing the associated array edit structure and this leads to a 512 byte memory leak each time an identical existing key is added with add_key(). The reason the add_key() system call returns okay is that key_create_or_update() calls __key_link_begin() before checking to see whether it can update a key directly rather than adding/replacing - which it turns out it can. Thus __key_link() is not called through __key_instantiate_and_link() and __key_link_end() must cancel the edit. CVE-2015-1333 Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mimi Zohar authored
commit f2b3dee4 upstream. The call to asymmetric_key_hex_to_key_id() from ca_keys_setup() silently fails with -ENOMEM. Instead of dynamically allocating memory from a __setup function, this patch defines a variable and calls __asymmetric_key_hex_to_key_id(), a new helper function, directly. This bug was introduced by 'commit 46963b77 ("KEYS: Overhaul key identification when searching for asymmetric keys")'. Changelog: - for clarification, rename hexlen to asciihexlen in asymmetric_key_hex_to_key_id() - add size argument to __asymmetric_key_hex_to_key_id() - David Howells - inline __asymmetric_key_hex_to_key_id() - David Howells - remove duplicate strlen() calls Acked-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Jarkko Sakkinen authored
commit b371616b upstream. At least some versions of AMI BIOS have corrupted contents in the TPM2 ACPI table and namely the physical address of the control area is set to zero. This patch changes the driver to fail gracefully when we observe a zero address instead of continuing to ioremap. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Jason Gunthorpe authored
commit ba0ef854 upstream. When a cdev is contained in a dynamic structure the cdev parent kobj should be set to the kobj that controls the lifetime of the enclosing structure. In TPM's case this is the embedded struct device. Also, cdev_init 0's the whole structure, so all sets must be after, not before. This fixes module ref counting and cdev. Fixes: 313d21ee ("tpm: device class for tpm") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by:
-
Hon Ching \\(Vicky\\) Lo authored
commit 9d75f089 upstream. tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq, the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address. Signed-off-by:
Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com> Signed-off-by:
Joy Latten <jmlatten@linux.vnet.ibm.com> Reviewed-by:
Ashley Lai <ashley@ahsleylai.com> Fixes: 132f7629 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by:
-
Jarkko Sakkinen authored
commit 49afd728 upstream. le64_to_cpu() was applied twice to the physical addresses read from the control area. This hasn't shown any visible regressions because CRB driver has been tested only on the little endian platofrms so far. Reported-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
David Fries authored
commit f7134eea upstream. A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by:
David Fries <David@Fries.net> Reported-By:
Thorsten Bschorr <thorsten@bschorr.de> Tested-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Brian Foster authored
commit f66bf042 upstream. The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that attribute blocks exist to invalidate. It is possible to have an attribute fork without extents, however. Consider the case where the attribute fork is created towards the beginning of xfs_attr_set() but some part of the subsequent attribute set fails. If an inode in such a state hits xfs_attr_inactive(), it eventually calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a filesystem corruption warning, returns an error that bubbles back up to xfs_attr_inactive(), and leads to destruction of the in-core attribute fork without an on-disk reset. If the inode happens to make it back through xfs_inactive() in this state (e.g., via a concurrent bulkstat that cycles the inode from the reclaim state and releases it), i_afp might not exist when xfs_bmapi_read() is called and causes a NULL dereference panic. A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB) reproduces these problems. The behavior is a regression caused by: 6dfe5a04 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind ... which removed logic that avoided the attribute extent truncate when no extents exist. Restore this logic to ensure the attribute fork is destroyed and reset correctly if it exists without any allocated extents. Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Eric Sandeen authored
commit 2ac56d3d upstream. If we create a CRC filesystem, mount it, and create a symlink with a path long enough that it can't live in the inode, we get a very strange result upon remount: # ls -l mnt total 4 lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM XSLM is the V5 symlink block header magic (which happens to be followed by a NUL, so the string looks terminated). xfs_readlink_bmap() advanced cur_chunk by the size of the header for CRC filesystems, but never actually used that pointer; it kept reading from bp->b_addr, which is the start of the block, rather than the start of the symlink data after the header. Looks like this problem goes back to v3.10. Fixing this gets us reading the proper link target, again. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
-
Martin K. Petersen authored
commit eab6ee1c upstream. Commit 5d3abf8f ("libata: Fall back to unqueued READ LOG EXT if the DMA variant fails") allowed us to fall back to the unqueued READ LOG variant if the queued version failed. However, if the device did not support the page at all we would end up looping due to a merge snafu. Ensure we only take the fallback path once. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reported-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Daniel Vetter authored
commit 5677d67a upstream. It's causing piles of issues since we've stopped forcing full detect cycles in the sysfs interfaces with commit c484f02d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 6 12:36:42 2015 +0000 drm: Lighten sysfs connector 'status' The original justification for this was that the hpd handlers could use the unknown state as a hint to force a full detection. But current i915 code isn't doing that any more, and no one else really uses reset on resume. So instead just keep the old state around. References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641 Cc: Rui Matos <tiagomatos@gmail.com> Cc: Julien Wajsberg <felash@gmail.com> Cc: kuddel.mail@gmx.de Cc: Lennart Poettering <mzxreary@0pointer.de> Acked-by:
Rob Clark <robdclark@gmail.com> Tested-by:
Rui Tiago Cação Matos <tiagomatos@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
commit c631d5f9 upstream. Frame buffer modifiers extensions provided in; commit e3eb3250 Author: Rob Clark <robdclark@gmail.com> Date: Thu Feb 5 14:41:52 2015 +0000 drm: add support for tiled/compressed/etc modifier in addfb2 Missed the structure packing/alignment problem where 64-bit members were added after the odd number of 32-bit ones. This makes the compiler produce structures of different sizes under 32- and 64-bit x86 targets and makes the ioctl need explicit compat handling. v2: Removed the typedef. (Daniel Vetter) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@intel.com> [danvet: Squash in compile fix from Mika.] Signed-off-by:
-
Zhao Junwang authored
commit 01447e9f upstream. legacy setcrtc ioctl does take a 32 bit value which might indeed overflow the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't needed any more with this v2: -polish the annotation according to Daniel's comment Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Zhao Junwang <zhjwpku@gmail.com> Signed-off-by:
-
Daniel Kurtz authored
commit 41315b79 upstream. Rather than (incompletely [0]) re-implementing drm_gem_mmap() and drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap routines. Once the core functions return successfully, the rockchip mmap routines can still use dma_mmap_attrs() to simply mmap the entire buffer. [0] Previously, we were performing the mmap() without first taking a reference on the underlying gem buffer. This could leak ptes if the gem object is destroyed while userspace is still holding the mapping. Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Reviewed-by:
-
Alex Deucher authored
commit bda5e3e9 upstream. This has been a source of confusion. Make it debug only. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
commit 12f1384d upstream. Port of amdgpu patch 9298e52f. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 5dfc71bc upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by:
-
Michel Dänzer authored
commit 233709d2 upstream. This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Grigori Goronzy authored
commit f3cbb17b upstream. Everything is evicted from VRAM before suspend, so we need to make sure all BOs are unpinned and re-pinned after resume. Fixes broken mouse cursor after resume introduced by commit b9729b17. [Michel Dänzer: Add pinning BOs on resume] v2: [Alex Deucher: merge cursor unpin into fb unpin loop] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541 Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by:
Grigori Goronzy <greg@chown.ath.cx> Signed-off-by:
-
Michel Dänzer authored
commit cd404af0 upstream. Take a GEM reference for and pin the new cursor BO, unpin and drop the GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use radeon_crtc->cursor_addr in radeon_set_cursor. This fixes radeon_cursor_reset accidentally incrementing the cursor BO pin count, and cleans up the code a little. Reviewed-by:
-
Mario Kleiner authored
commit 07f18f0b upstream. Trying to resolve issues with missed vblanks and impossible values inside delivered kms pageflip completion events showed that radeon's irq handling sometimes doesn't handle valid irqs, but silently skips them. This was observed for vblank interrupts. Although those irqs have corresponding events queued in the gpu's irq ring at time of interrupt, and therefore the corresponding handling code gets triggered by these events, the handling code sometimes silently skipped processing the irq. The reason for those skips is that the handling code double-checks for each irq event if the corresponding irq status bits in the irq status registers are set. Sometimes those bits are not set at time of check for valid irqs, maybe due to some hardware race on some setups? The problem only seems to happen on some machine + card combos sometimes, e.g., never happened during my testing of different PC cards of the DCE-2/3/4 generation a year ago, but happens consistently now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen at each interrupt but only occassionally every couple of hundred or thousand vblank interrupts. This results in XOrg warning messages like "[ 7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 420120 < target_msc 420121" as well as skipped frames and problems for applications that use kms pageflip events or vblank events, e.g., users of DRI2 and DRI3/Present, Waylands Weston compositor, etc. See also https://bugs.freedesktop.org/show_bug.cgi?id=85203 After some talking to Alex and Michel, we decided to fix this by turning the double-check for asserted irq status bits into a warning. Whenever a irq event is queued in the IH ring, always execute the corresponding interrupt handler. Still check the irq status bits, but only to log a DRM_DEBUG message on a mismatch. This fixed the problems reliably on both previously failing cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2) and a triple-output Juniper HD-5770 card tested on all three available crtcs (D1/D2/D3). The r600 and evergreen irq handling is therefore tested, but the cik an si handling is only compile tested due to lack of hw. Reviewed-by:
Mario Kleiner <mario.kleiner.de@gmail.com> CC: Michel Dänzer <michel.daenzer@amd.com> CC: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Grigori Goronzy authored
commit 54e03986 upstream. This was regressed by commit 39e7f6f8, although I don't know of any actual issues caused by it. The storage domain is read without TTM locking now, but the lock never helped to prevent any races. Reviewed-by:
-
Alex Deucher authored
commit 479e9a95 upstream. Avoids a crash on pre-DP asics that support HDMI. Signed-off-by:
-
Alex Deucher authored
commit ac913490 upstream. This reverts commit b9729b17. This seems to break the cursor on resume for lots of systems. Signed-off-by:
-
Jérôme Glisse authored
commit 2ba8d1bb upstream. In order for hibernation to reliably work we need to properly turn off the SDMA block, sadly after numerous attemps i haven't not found proper sequence for clean and full shutdown. So simply reset both SDMA block, this makes hibernation works reliably on sea island GPU family (CI) Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Reviewed-by:
-
Jérôme Glisse authored
commit 161569de upstream. In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which correspond to a suspend inside the radeon kernel driver) and turn off each of the block. It turns out we were not cleanly shutting down the compute ring. This patch fix that. Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Changed since v1: - Factor the ring stop logic into a function taking ring as arg. Signed-off-by:
-
Chris Wilson authored
commit 648a9bc5 upstream. Since the hardware sometimes mysteriously totally flummoxes the 64bit read of a 64bit register when read using a single instruction, split the read into two instructions. Since the read here is of automatically incrementing timestamp counters, we also have to be very careful in order to make sure that it does not increment between the two instructions. However, since userspace tried to workaround this issue and so enshrined this ABI for a broken hardware read and in the process neglected that the read only fails in some environments, we have to introduce a new uABI flag for userspace to request the 2x32 bit accurate read of the timestamp. v2: Fix alignment check and include details of the workaround for userspace. Reported-by:
Karol Herbst <freedesktop@karolherbst.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317 Testcase: igt/gem_reg_read Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Tested-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit d82c0ba6 upstream. This reverts commit 19ee835c. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen <harald@skogtun.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Harald Arnesen <harald@skogtun.org> Signed-off-by:
-
Tvrtko Ursulin authored
commit ac7e7ab1 upstream. Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by:
-
Tomas Elf authored
commit 94f7bbe1 upstream. The hang checker needs to inspect whether or not the ring request list is empty as well as if the given engine has reached or passed the most recently submitted request. The problem with this is that the hang checker cannot grab the struct_mutex, which is required in order to safely inspect requests since requests might be deallocated during inspection. In the past we've had kernel panics due to this very unsynchronized access in the hang checker. One solution to this problem is to not inspect the requests directly since we're only interested in the seqno of the most recently submitted request - not the request itself. Instead the seqno of the most recently submitted request is stored separately, which the hang checker then inspects, circumventing the issue of synchronization from the hang checker entirely. This fixes a regression introduced in commit 44cdd6d2 Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:40 2014 +0000 drm/i915: Convert 'ring_idle()' to use requests not seqnos v2 (Chris Wilson): - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather than compute it over again. - Remove extra whitespace. Issue: VIZ-5998 Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Reviewed-by:
-
Chris Wilson authored
commit 19ee835c upstream. The old style of memory interleaving swizzled upto the end of the first even bank of memory, and then used the remainder as unswizzled on the unpaired bank - i.e. swizzling is not constant for all memory. This causes problems when we try to migrate memory and so the kernel prevents migration at all when we detect L-shaped inconsistent swizzling. However, this issue also extends to userspace who try to manually detile into memory as the swizzling for an individual page is unknown (it depends on its physical address only known to the kernel), userspace cannot correctly swizzle objects. v2: Mark the global swizzling as unknown rather than adjust the value reported to userspace. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105Signed-off-by:
-
Jani Nikula authored
commit 2059ac3b upstream. Some 855gm models (at least ThinkPad X40) regressed because of commit b0cd324f Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 12 16:25:43 2014 +0200 drm/i915: don't save/restore backlight hist ctl registers which tried to make our driver more robust by not blindly saving and restoring registers, but it failed to take into account commit 0eb96d6e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Oct 14 12:33:41 2009 -0700 drm/i915: save/restore BLC histogram control reg across suspend/resume Fix the regression by enabling hist ctl on gen2. v2: Improved the comment. v3: Improved the comment, again. Reported-and-tested-by:
Philipp Gesang <phg@phi-gamma.net> References: http://mid.gmane.org/20150623222648.GD12335@acheron Fixes: b0cd324f ("drm/i915: don't save/restore backlight hist ctl registers") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
commit ac88cd73 upstream. We cannot let IPS enabled with no plane on the pipe: BSpec: "IPS cannot be enabled until after at least one plane has been enabled for at least one vertical blank." and "IPS must be disabled while there is still at least one plane enabled on the same pipe as IPS." This restriction apply to HSW and BDW. However a shortcut path on update primary plane function to make primary plane invisible by setting DSPCTRL to 0 was leting IPS enabled while there was no other plane enabled on the pipe causing flickerings that we were believing that it was caused by that other restriction where ips cannot be used when pixel rate is greater than 95% of cdclok. v2: Don't mess with Atomic path as pointed out by Ville. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Michel Thierry authored
commit 00245266 upstream. If for some reason [1], the page directory/table does not exist, clear_range would end up in an infinite while loop. Introduced by commit 06fda602 ("drm/i915: Create page table allocators"). [1] This is already being addressed in one of Mika's patches: http://mid.gmane.org/1432314314-23530-17-git-send-email-mika.kuoppala@intel.com Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reported-by:
John Harrison <john.c.harrison@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Alex Deucher authored
commit 01062193 upstream. - make it static - fix mask/bool handling for last param Signed-off-by:
-
Alex Deucher authored
commit 39fa10f7 upstream. Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by:
-
Andrey Ryabinin authored
commit 60f207a5 upstream. for_each_*_in_state validate array index after access to array elements, thus perform out of bounds read. Fix this by validating index in the first place and read array element iff validation was successful. Fixes: df63b999 ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros") Signed-off-by:
Andrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit dad3c350 upstream. If GPIOLIB=n and asm-generic/gpio.h is not used: drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_pre_enable’: drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of function ‘gpiod_set_value’ drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_probe’: drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of function ‘devm_gpiod_get’ drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer from integer without a cast drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of function ‘gpiod_direction_output’ drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer from integer without a cast Add the missing #include <linux/gpio/consumer.h> to fix this. Fixes: af478d88 ("drm/bridge: ptn3460: use gpiod interface") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Frediano Ziglio authored
commit 8451cc96 upstream. If the function fails reference counter to the object is not decremented causing leaks. This is hard to spot as it happens only on very low memory situations. Signed-off-by:
Frediano Ziglio <fziglio@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Frediano Ziglio authored
commit 2fa19535 upstream. If objects are moved back from system memory to VRAM (and spice id created again) memory is already initialized so we need to set flag to not clear memory. If you don't do it after a while using desktop many images turns to black or transparents. Signed-off-by:
-
