kernel/linux.git/drivers/video/fbdev/hyperv_fb.c, branch v5.10.78

video: hyperv_fb: Fix a double free in hvfb_probe

2021-04-07T13:00:11+00:00

[ Upstream commit 37df9f3fedb6aeaff5564145e8162aab912c9284 ] Function hvfb_probe() calls hvfb_getmem(), expecting upon return that info->apertures is either NULL or points to memory that should be freed by framebuffer_release(). But hvfb_getmem() is freeing the memory and leaving the pointer non-NULL, resulting in a double free if an error occurs or later if hvfb_remove() is called. Fix this by removing all kfree(info->apertures) calls in hvfb_getmem(). This will allow framebuffer_release() to free the memory, which follows the pattern of other fbdev drivers. Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.") Signed-off-by: Lv Yunlong Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20210324103724.4189-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Merge tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2020-11-23T23:29:03+00:00

Pull Hyper-V fix from Wei Liu: "One patch from Dexuan to fix VRAM cache type in Hyper-V framebuffer driver" * tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: video: hyperv_fb: Fix the cache type when mapping the VRAM

video: hyperv_fb: Fix the cache type when mapping the VRAM

2020-11-20T12:24:14+00:00

x86 Hyper-V used to essentially always overwrite the effective cache type of guest memory accesses to WB. This was problematic in cases where there is a physical device assigned to the VM, since that often requires that the VM should have control over cache types. Thus, on newer Hyper-V since 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM users start to complain that Linux VM's VRAM becomes very slow, and it turns out that Linux VM should not map the VRAM uncacheable by ioremap(). Fix this slowness issue by using ioremap_cache(). On ARM64, ioremap_cache() is also required as the host also maps the VRAM cacheable, otherwise VM Connect can't display properly with ioremap() or ioremap_wc(). With this change, the VRAM on new Hyper-V is as fast as regular RAM, so it's no longer necessary to use the hacks we added to mitigate the slowness, i.e. we no longer need to allocate physical memory and use it to back up the VRAM in Generation-1 VM, and we also no longer need to allocate physical memory to back up the framebuffer in a Generation-2 VM and copy the framebuffer to the real VRAM. A further big change will address these for v5.11. Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver") Tested-by: Boqun Feng Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Reviewed-by: Haiyang Zhang Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com Signed-off-by: Wei Liu

video: hyperv_fb: include vmalloc.h

2020-11-09T07:17:46+00:00

hvfb_getmem uses vzalloc, therefore vmalloc.h should be included. Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Signed-off-by: Olaf Hering Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201106183941.9751-1-olaf@aepfle.de

hyperv_fb: Update screen_info after removing old framebuffer

2020-10-14T15:05:26+00:00

On gen2 HyperV VM, hyperv_fb will remove the old framebuffer, and the new allocated framebuffer address could be at a differnt location, and it might be no longer a VGA framebuffer. Update screen_info so that after kexec the kernel won't try to reuse the old invalid/stale framebuffer address as VGA, corrupting memory. [ mingo: Tidied up the changelog. ] Signed-off-by: Kairui Song Signed-off-by: Ingo Molnar Cc: Dexuan Cui Cc: Jake Oshins Cc: Wei Hu Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Link: https://lore.kernel.org/r/20201014092429.1415040-3-kasong@redhat.com

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59+00:00

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva

Merge tag 'drm-misc-next-2020-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2020-02-20T19:44:40+00:00

drm-misc-next for 5.7: UAPI Changes: - lima: Add support for heap buffers Cross-subsystem Changes: Core Changes: - Implement mode_config mode_valid for memory constrained drivers - Bus format negociation between bridges - Consolidate fake vblank events for drivers without vblank interrupts - drm/bufs: dma_alloc related cleanups - drm/dp_mst: Various fixes - drm/print: New drm_device based print helpers - Thomas is a drm-misc maintainer now! Driver Changes: - DPMS cleanups for atomic drivers - Removal of owner field in SPI tinydrm drivers - Removal of explicit dependency on DT for tinydrm drivers - Conversion to YAML schemas for DT bindings - tidss: New driver - virtio: various reworks and fixes - Our usual dozen or so new panels or bridges Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan

Merge tag 'hyperv-next-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2020-02-03T14:42:03+00:00

Pull Hyper-V updates from Sasha Levin: - Most of the commits here are work to enable host-initiated hibernation support by Dexuan Cui. - Fix for a warning shown when host sends non-aligned balloon requests by Tianyu Lan. * tag 'hyperv-next-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: hv_utils: Add the support of hibernation hv_utils: Support host-initiated hibernation request hv_utils: Support host-initiated restart request Tools: hv: Reopen the devices if read() or write() returns errors video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs. Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23) video: hyperv_fb: Fix hibernation for the deferred IO feature Input: hyperv-keyboard: Add the support of hibernation hv_balloon: Balloon up according to request page number

video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.

2020-01-27T02:22:19+00:00

On Hyper-V, Generation 1 VMs can directly use VM's physical memory for their framebuffers. This can improve the efficiency of framebuffer and overall performence for VM. The physical memory assigned to framebuffer must be contiguous. We use CMA allocator to get contiguouse physicial memory when the framebuffer size is greater than 4MB. For size under 4MB, we use alloc_pages to achieve this. To enable framebuffer memory allocation from CMA, supply a kernel parameter to give enough space to CMA allocator at boot time. For example: cma=130m This gives 130MB memory to CAM allocator that can be allocated to framebuffer. If this fails, we fall back to the old way of using mmio for framebuffer. Reported-by: kbuild test robot Signed-off-by: Wei Hu Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin

video: hyperv_fb: Fix hibernation for the deferred IO feature

2020-01-25T21:52:11+00:00

fb_deferred_io_work() can access the vmbus ringbuffer by calling fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update(). Because the vmbus ringbuffer is inaccessible between hvfb_suspend() and hvfb_resume(), we must cancel info->deferred_work before calling vmbus_close() and then reschedule it after we reopen the channel in hvfb_resume(). Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation") Signed-off-by: Dexuan Cui Reviewed-by: Wei Hu Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin