From patchwork Mon Jan 11 13:01:52 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 360990 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60FD2C433E0 for ; Mon, 11 Jan 2021 13:45:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3A53222211 for ; Mon, 11 Jan 2021 13:45:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731411AbhAKNLb (ORCPT ); Mon, 11 Jan 2021 08:11:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:58310 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731405AbhAKNLa (ORCPT ); Mon, 11 Jan 2021 08:11:30 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E93E722B49; Mon, 11 Jan 2021 13:11:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1610370674; bh=Y88JrtSnJigugINxiQIwypf7dwV/4rm8VVeXFG57HYY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N718UyMVzi3edaveVAusqEjyAm7qFfiE9aDO6Jxl1txKMfB2E9UkMeZSi06Wb8g6b wECilPAIAmA8DrGG6PjEi7dD7o1LZKh5ZjcV8+Dqu3YsYw7FDa58MAdTdJtXe9XY0A EJRIzKfDBjaZ1+no8S45jgSMjBQr/Rb3BxeGEX5Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dexuan Cui , Sasha Levin Subject: [PATCH 5.4 48/92] video: hyperv_fb: Fix the mmap() regression for v5.4.y and older Date: Mon, 11 Jan 2021 14:01:52 +0100 Message-Id: <20210111130041.456762660@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210111130039.165470698@linuxfoundation.org> References: <20210111130039.165470698@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dexuan Cui db49200b1dad is backported from the mainline commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping the VRAM"), to v5.4.y and older stable branches, but unluckily db49200b1dad causes mmap() to fail for /dev/fb0 due to EINVAL: [ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back This means the v5.4.y kernel detects an incompatibility issue about the mapping type of the VRAM: db49200b1dad changes to use Write-Back when mapping the VRAM, while the mmap() syscall tries to use Uncached-minus. That’s to say, the kernel thinks Uncached-minus is incompatible with Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() -> vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() -> reserve_pfn_range(). Note: any v5.5 and newer kernel doesn't have the issue, because they have commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") , and when the hyperv_fb driver has the deferred_io support, fb_deferred_io_init() overrides info->fbops->fb_mmap with fb_deferred_io_mmap(), which doesn’t check the mapping type incompatibility. Note: since it's VRAM here, the checking is not really necessary. Fix the regression by ioremap_wc(), which uses Write-combining. The kernel thinks it's compatible with Uncached-minus. The VRAM mappped by ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is still significantly faster than by ioremap(). Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not working in the latest mainline yet, and when it works in future, the ARM64 support is unlikely to be backported to v5.4 and older, so using ioremap_wc() in v5.4 and older should be ok. Note: this fix is only targeted at the stable branches: v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y. Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM") Signed-off-by: Dexuan Cui Signed-off-by: Sasha Levin --- drivers/video/fbdev/hyperv_fb.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c index 81671272aa58f..1c6ae98710a01 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -704,11 +704,9 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info) } /* - * Map the VRAM cacheable for performance. This is also required for - * VM Connect to display properly for ARM64 Linux VM, as the host also - * maps the VRAM cacheable. + * Map the VRAM cacheable for performance. */ - fb_virt = ioremap_cache(par->mem->start, screen_fb_size); + fb_virt = ioremap_wc(par->mem->start, screen_fb_size); if (!fb_virt) goto err2;