From patchwork Fri May 23 16:15:19 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: mhkelley58@gmail.com X-Patchwork-Id: 892297 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34787225D7; Fri, 23 May 2025 16:15:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016945; cv=none; b=T75JEoOu4vMQmWP1jXiATs+QPzqmgHtUfUaaGD0SDBqdl/tZk6nnG5mPuACh1+C0MHcy2egRKXk3RVOiciH5EFQZ7ZP5Hhjo1Jt0yDGcmIK2w4K0g1humN30Za2PK2wRzPODRmJB+gfxwLMzHeruk39sVX2YxCDUfCcLf4ILapo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016945; c=relaxed/simple; bh=fDObmogM+dfq6hZJ4xJNyjAocz1Nh6uxvjdVqYWVN1E=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=uwdEcSdxJ6kFJAC5qGZkHuk/xF4TH5ByNNtUA9nFDfHj9vaRvgPJ/qEv6yCdjFUrh/WGSP8HD7/cToyeqNxmIMFNMRFVDbEbdaH3QwVpqM5RO326DO5NtwnabO0GjkYXe5QlhcRtSqOFW4thnXkZsYQxkLhlHCs0jI96vwxCdls= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BLMaqmBQ; arc=none smtp.client-ip=209.85.216.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BLMaqmBQ" Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-30820167b47so147926a91.0; Fri, 23 May 2025 09:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748016943; x=1748621743; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=6Ci3isxxhsp5k7AjuUnYW4WXxlffmz+Qa/1SXSaaPCI=; b=BLMaqmBQivR3vehb4LPODls7Rx6Vjt/6vAJB2417+68he/0kVHL13V2gB5zAGzNl20 k5t957AQ/fKHhf89ihAawrwblWOkvptgVbYmllNbwp4qGeCWcNtfIvViDHS9ZbYZLlqy pAiTIFbUIiXtYxYZ0wdI3TP3tjY78oWtUEnzCWcDneoqjWODdYIhegnLK9PXmDeJZ2D7 459BMi5nZkBtg+nb/wkwWuRgOAcRhoewct2Mz9dktbj9+Rpy+SM+9mXPlXTIvG1KMxG6 dhVahLL0VaKBvZ+8pndRan3/PfIkMaoo13rf/TfJq+KDVji1lSk3LEeYZR31UYMuE3oq XfNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748016943; x=1748621743; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6Ci3isxxhsp5k7AjuUnYW4WXxlffmz+Qa/1SXSaaPCI=; b=YfddyV1QeHXlQtLCxKkLaPdfSCMWVzJxQS9KncUid5qhf/O1qLR7P3uaNiwj97ErQa s10kA13SGgCYZ/A64059kol+RlTsLTzYrMJ8vk6OKl+9brGmAkDyyYS78I1ERdHPiGfk mI6mO1vQnN/XIIF6EI2c0KQAPZNriXjs92CpHQ3jiSvNHIhJdABiZl1rhplHcmcARL6O 4UfY9ejMn4yvHNI642PPh97FetztLotjp8x8I3TKiyoYvw1DUDlnUZA3qgrSc/UDTyQZ 2dcYBrrgCkar4eTeyoDdVDkrcDkIDB0BCr3LgjjeFQLv3dl1apS4VrD/XQ3fVRqdXQ49 GE0Q== X-Forwarded-Encrypted: i=1; AJvYcCW2Z0qSth2KxW2sejGfXfPgCjPKUBK3aKq4jbIJX+X57bkHFpBDaS54cSxaTDMl8s9LLQm1EGRyHrPurnaV@vger.kernel.org, AJvYcCWSppcEZbQY/qPumSzSfL46P3zdwdqlxDa27iCEqA1nReAPONZ8/KHYIZx40Y8pFedi/uUTi9GjfQtqNw==@vger.kernel.org, AJvYcCX97712fV7nREKw4zUdfBC++mvJXlh9/WqXbwDniOZWpBxi/PPgZh/BDk9HzZTsQzJen937anlkNwd+v+MB@vger.kernel.org X-Gm-Message-State: AOJu0YzS+mCJTPRnu4HWHjmW32Cu2f495BqWa/AxB6RArKbwillWpha3 7SKJxJQNYxJaSe4/E7jF8ur5UfsD99Ys6q/bmkWP4Lcju3G1MQMhaO9M X-Gm-Gg: ASbGnct2vQz7KvZN+MLb5RCX+OV/IBjQvyFeQHWAwWw6CAJFj3NUbucG3FFZttrNEg6 ilaYheIKI3tVw6cpg3z3v8VFat9K3Il3N2rRxH/QwOf41FcP3sp45KGGmtNIUgwheitJOS2AcLh ueK9w5V8DM3imnRUs4m4KRovVm9O1F9v1lckWs4BdXXNA+aX1UtTQn81ElE3HBPmDXvMEXIgQGG TTe3iZEsN4yHsUzNTeOWJQDb1ZICjVJUBpZMzMZ5OotQkdTnAtZhHgq0SMecZ5xQT++XjpcVxMV 5ETRQck3dVyUbdx+RJC0c/YIig6fLuZEDyO6UjSjqgQkOcZIpAT2/kA3RGt3i3kP0hcWYw6QfDD RsuJbQBbrDGU0OWiGDMQDSOS6cuExTZ2uSiiC6G33 X-Google-Smtp-Source: AGHT+IE8pcy7Z2wW7SrWmR8EeORXq3Lf3Mz2nUIbKMce/zPJlwY6YhtwhHMP/X+hsVmxnhhRfKeaCQ== X-Received: by 2002:a17:90b:3889:b0:2ff:5267:e7da with SMTP id 98e67ed59e1d1-3110ac9b71fmr132826a91.3.1748016943353; Fri, 23 May 2025 09:15:43 -0700 (PDT) Received: from localhost.localdomain (c-67-160-120-253.hsd1.wa.comcast.net. [67.160.120.253]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30f365d46ffsm7526565a91.25.2025.05.23.09.15.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 May 2025 09:15:43 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: simona@ffwll.ch, deller@gmx.de, haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, akpm@linux-foundation.org Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 1/4] mm: Export vmf_insert_mixed_mkwrite() Date: Fri, 23 May 2025 09:15:19 -0700 Message-Id: <20250523161522.409504-2-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com> References: <20250523161522.409504-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Michael Kelley Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code, which can be built as a module. Commit cd1e0dac3a3e ("mm: unexport vmf_insert_mixed_mkwrite") is effectively reverted. Signed-off-by: Michael Kelley --- Changes in v2: * Exported as GPL symbol [Christoph Hellwig] mm/memory.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/memory.c b/mm/memory.c index 5cb48f262ab0..58ba40a676c9 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2688,6 +2688,7 @@ vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma, { return __vm_insert_mixed(vma, addr, pfn, true); } +EXPORT_SYMBOL_GPL(vmf_insert_mixed_mkwrite); /* * maps a range of physical memory into the requested pages. the old From patchwork Fri May 23 16:15:20 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: mhkelley58@gmail.com X-Patchwork-Id: 892103 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B2151F0E37; Fri, 23 May 2025 16:15:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016946; cv=none; b=eoVcsb+e71KmrUnik8ojfeDbG5Uf2EQH5UTHZHjpXVenJH2OW647CQva32XnjLgjv70+fji6Ns120NH04y9sNMhL5t7Seb1liKdT/EdpBROD0zmDkJ7UZwhTJr+bTLUhPk1b63tJl/tZbvir92K/2tdZRWQW6JJjvewxt2OXBG0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016946; c=relaxed/simple; bh=hz0JB9pzXQpSDr6pAMFPj1hF1BZKOfjGC0sQ6kmOQIs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fwqL3P46HSgsyJTvYVHryasHf7+Y311tanhjXUEBNP6Scq9njZ3GhZVaKWVkad/I9F+0HSC6lF1RoJW9OTbZOBPHauPv5q5DRdKOd6SFLsnV6oN+R1nQwT9H9JvEhTXWiJF2yeF3Z6gcloJrYwQzxFolj/EDudRajwtRVlFqaI0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LpoufZkw; arc=none smtp.client-ip=209.85.216.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LpoufZkw" Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-30ea8b7c5c2so115259a91.3; Fri, 23 May 2025 09:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748016944; x=1748621744; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=fcO9TXDJbv0PnpLhAYEgKHbgViS8WVoRG/IIez/PTTM=; b=LpoufZkwN19VCywWq9GHD9nNqlitZwRXJqamadrGJvNhd+6Ky8MYfEU4yLGhHhteyE 1pc9UWwjRT0xznLWBANzfyB7tv3YHMnT9Zf2JsGFCDLj0D1hp1IXp/HHTNqYPFE2NI4w 9S5PnrKjG6T+ViM+ev18HH9r79No43bdwsb5cwQPYd6a9H1RVPlCfxVrlG9B7DQHt9OS WomxwLGmW7yJoMiTH1x6BGAW3NsC5Y/0th/OB64Ct7/e+/mnJFIwaWpkziFsoJ0PULIC JGiAuZrHHZ8Wc7VcksmotMK6H6oisauAaGO8HHnIOZqneZM/119zCI2xy/mWPf5rWscE FBEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748016944; x=1748621744; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fcO9TXDJbv0PnpLhAYEgKHbgViS8WVoRG/IIez/PTTM=; b=DxDJ4rf0PdxyrHaZVPD7UUX50Q0/c6XAHdeVyrDmL8AM5kPSgf4tMENxx8wdgxw1rE ReIFQKs9aPFf3qeLxkEc42m7nR6HD4DLD0yGdQ3MeLCEtGr2GpS3sIJC27QdDFlrt5fF keIOBJpe5wjlbHW8li/dsqtScbCmc1OSavnz9C9rXy/36KJm46DNmgZbZVbLvIyTXfs1 TZGhs7ZruYkqPnv0+vq+P+dij/bkyRqTxYpgcUTi6BdBFi5KNktZdiaZl4OqMmJtYq3q rUY9pMsRkChY/CIFXnoXCGoBSTB12JG4PiZh/WSM8TZipFMrdLWduJAg62MhzMWSlqTX ALbw== X-Forwarded-Encrypted: i=1; AJvYcCVr+MtDsMxTuLS5e6k7fWCSmkypSAArjhGq1Lbv/CnkUnb1dKXjlUqjMGfkYqvwDcLAnbmu19ETXzZmpryz@vger.kernel.org, AJvYcCWF262j+WK4Vw/d2AnH1CjtbvGX6pQqDaXGvjeATWudnLE0he/MSodNFiWGHYdk80V5SyXFir1RTRTVRQ==@vger.kernel.org, AJvYcCXnhOZX2VioUW+N/zQbvKUxWC0rPMh9TijOXVPPlqaG7e0mQVEv9fKnZmV9zCNHpZpjsB0NKAWognaca+0f@vger.kernel.org X-Gm-Message-State: AOJu0YwpkMCflZ41FbC2CtCm8MBLoB93LX2d0MTzFURuwLRv6MAZbD1s 4FIMWVvtIRXqg4FyLwC5lLJB6+4FkRIjHIwU+FsrURN3HnVBDnnZPP8R X-Gm-Gg: ASbGnctdTXjCN0vJNl4qzP4HvVUmElQTDENnZDeut4ladVqi0AJMf5h7GIxDDU2aerr XLQzPCoJC6ry3F4kXzkZbfLpxz/x5iIzOsL08rXY6HHCEsTdEDX0S1LQXQDQDrKoYeSwclrAKlk Cnz0iGPFBAtgMvZAHref5Rh7nobIFHgVdp372yWQOL35Ujf//1njojQ8vURfOgkjuXS9hbTnOok n1tLj8rxkFw+gp4sZinHgEVYzQmWfQvYYCLzTwmSsVInETGKgrMIrtfdYfXObe0h+e0YDzwIx5a ZcDBZvHqXwarvYZ88eG03bg/sKQ6opeQawgCQB867jg8hCj0uh6hNwmOZsL6iNVRaYrNsgdTr7h r+l+vzkfltRjV3jHJBFZVeTOYYY4bZEVmRO+wkc4q X-Google-Smtp-Source: AGHT+IEBtJgfUd9PfG81gZCPku8xlj3yj9p8H5N/t60M0ZS5vpK6dBsg3ehnSMHrskKHTMOTXKcvtw== X-Received: by 2002:a17:90b:48ce:b0:2ee:d371:3227 with SMTP id 98e67ed59e1d1-30e7d53fedcmr53004820a91.17.1748016944385; Fri, 23 May 2025 09:15:44 -0700 (PDT) Received: from localhost.localdomain (c-67-160-120-253.hsd1.wa.comcast.net. [67.160.120.253]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30f365d46ffsm7526565a91.25.2025.05.23.09.15.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 May 2025 09:15:44 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: simona@ffwll.ch, deller@gmx.de, haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, akpm@linux-foundation.org Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 2/4] fbdev: Add flag indicating framebuffer is allocated from kernel memory Date: Fri, 23 May 2025 09:15:20 -0700 Message-Id: <20250523161522.409504-3-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com> References: <20250523161522.409504-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Michael Kelley Add a flag that fbdev drivers can set to indicate that the framebuffer memory comes from alloc_pages() or similar as opposed to vmalloc() memory. The flag is to be used by fbdev deferred I/O. Signed-off-by: Michael Kelley --- Changes in v3: * This patch is new in v3. The definition of FBINFO_KMEMFB was previously combined into the next patch of the series. [Helge Deller] include/linux/fb.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/fb.h b/include/linux/fb.h index 05cc251035da..a1121116eef0 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -396,6 +396,7 @@ struct fb_tile_ops { /* hints */ #define FBINFO_VIRTFB 0x0004 /* FB is System RAM, not device. */ +#define FBINFO_KMEMFB 0x0008 /* FB is allocated in contig kernel mem */ #define FBINFO_PARTIAL_PAN_OK 0x0040 /* otw use pan only for double-buffering */ #define FBINFO_READS_FAST 0x0080 /* soft-copy faster than rendering */ From patchwork Fri May 23 16:15:21 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: mhkelley58@gmail.com X-Patchwork-Id: 892296 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 788ED296FAB; Fri, 23 May 2025 16:15:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016948; cv=none; b=ZwPucciaGsqnTeGx85yYveg8slm0JQ23UEe2VjDGEqlUHtOYYJbAMjf8Q8/ejW2apfZWEgtHh8r/dEgtLtzKHaicZtGT1qs585m5AgKuTHjSzaT8M35DYtrsjhOz9O54pWJArBv+LmG0j+mwGAdcnzU5fnAkeAGdaXJxLGCRY3o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016948; c=relaxed/simple; bh=58HG41QzO98GYhQQcnvlsAQOtnfbo5y/cL4oAaFfdE0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=ooxjoxzrmlgKZrv+n5KNdTWvLAqOMBKL1Far23dFCpkSuHmban6EF+4m41KWH4DeF+saJzQDX+67rQgHvvYjqyEk761TAJbQmYP3vGwhSBJHH6ZlUCVBOTWCiloDC3fkZNZmKx71QqJWrGbCXH7+hA3xG2htU2uj0qNYXaI2+eE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WYOZ1Z5/; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WYOZ1Z5/" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-30ea7770bd2so155585a91.0; Fri, 23 May 2025 09:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748016946; x=1748621746; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=wUiI7uurtmihv+UWHjMJ6FiZApPhjGbJwo1AeiH3TYo=; b=WYOZ1Z5/hxeRUnl9PDkk028/b+u1fQrvagoymYyM0pwy8Q5hjWlFo4QNNtK/qwwOkG evbttiOEHuE+Mf1aSHkXIYpTJ9Jyjlo279OqAOgTub6CnnuM9goK3jDsQIA7+QRW2U3i ayUGSqEOnUKzBD/kIN5NcQ/7iX5T8Ki8CqLtqWfFZfRC+cLxKJv0WGxvRnD8hysOGDLf 7LuW7Rd7HOa5LMGSPt3zGvi8NcfkUwbpm42LnNmKjKuV5Gv+uAgwyCv7Am6G+LoJ/fPZ LCpvmCHvvH8veW5y4hIAmCw1Dkr2I4KxZ/AI4jBCPX0anBNKsdWYuTXgdN+M2/4oQiil mqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748016946; x=1748621746; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wUiI7uurtmihv+UWHjMJ6FiZApPhjGbJwo1AeiH3TYo=; b=BUzVAqVhy6SpSThrVQ6Dfh+n3A/VBvng4XWtcfbV4QGBeml+Sm9kJUdzzrC29t4OsD I8z7RkO3cpDSR+E1qKh0qT9LKcC99yO8sXr2kR6zNLxR8WxX1Oie7h6qmqul0ol/hWhD LjXgBoniuaO6Ue/oQEtMvGarZ+vaKqnfHme4qlbfOM0jWkq5hJXs3VJgl6cp2EA2sNX/ eb9pR9IfrlsG4IuSdwkLfnSxvk5hLpIcILYKRfbhcFcjNmL/DET5123wfrLM51rbeNVU cW9cy3K0DOyb+qRGF9zLoJ1HJtGf0cr82Ue+svvnOJ7cEnwJA/stAfOqI2te0cojrHxU 2mzQ== X-Forwarded-Encrypted: i=1; AJvYcCVxFsy5xfvti9S4SxjoH1SGxlSTzyRoi4ZMpXMsRxc//WuoNnIe2pOwGRD7KsxImVGHn8U4c65rtWh5JA==@vger.kernel.org, AJvYcCWBrJlehceOe5MQ8kbHmJELmpik3Yy+S2GrPrszvRVbJFkygVw//IWFV0z6lRWUHuQZrsVvos60vRbd31L7@vger.kernel.org, AJvYcCX0k1UPh44jh/D8ws6j4uicHKrK5KX45p7VkjnUdicSDZeRQHph5PxYQBFCSeGGjf2BpQ7uOeYLTR35RXcx@vger.kernel.org X-Gm-Message-State: AOJu0YxOWInvUU9IfKhdHmDZjI19Q+yBXSvGFz+WMNXXg+N8RdCO4n/r 4d1miBvCA4Kgv8s7ayeVzNtM01oF8vfVQzLnQWeoiZPZyDK4BtT/qqsb X-Gm-Gg: ASbGncv2GAnTs7QCEZjbwI2Aa97L0+f7VH0ID528GSKZxFBY5HmY3FyEEyfD4o9TNdd d4ImebGTpUV+juZMPmK21g2TbreLfaNs8FHobS2GHj/JNKG/jM7VD3JqXSaWeV9Ppajg7VDhi82 E9gWvtN67Cvyt1EgD9aai6ntJ9EUV1XgLw/JYHkOaggBU4TmdiU96MsKZ7dpSyFEIEcqVliK++M AZHYzBuwqjOlRMswsu0X8GXj5p+3aCaEwxw0thxjtgkFG6FxGNBleg4um9rIIn6ekTUmmjfEyFx wD8amSs6ZxprrNn3mrNPz/TRshbcnzpaDZQ1UvnZEBW+hR5oZDKM4gaZKuRXCJgfAzdKkq6eUgJ xC/NvF2wj4B7aXmB2PViUkzYvysD6lX5vhgN9nDHh X-Google-Smtp-Source: AGHT+IHZaxwJ79cc+ke533wgd3iPzfray3lMS/1ONJk0NIBROI1NmeDHZii9+TWr1XyrOD/clKoaLA== X-Received: by 2002:a17:90b:38c5:b0:30e:9aa2:6d34 with SMTP id 98e67ed59e1d1-30e9aa26e5bmr45205405a91.0.1748016945520; Fri, 23 May 2025 09:15:45 -0700 (PDT) Received: from localhost.localdomain (c-67-160-120-253.hsd1.wa.comcast.net. [67.160.120.253]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30f365d46ffsm7526565a91.25.2025.05.23.09.15.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 May 2025 09:15:45 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: simona@ffwll.ch, deller@gmx.de, haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, akpm@linux-foundation.org Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers Date: Fri, 23 May 2025 09:15:21 -0700 Message-Id: <20250523161522.409504-4-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com> References: <20250523161522.409504-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Michael Kelley Current defio code works only for framebuffer memory that is allocated with vmalloc(). The code assumes that the underlying page refcount can be used by the mm subsystem to manage each framebuffer page's lifecycle, including freeing the page if the refcount goes to 0. This approach is consistent with vmalloc'ed memory, but not with contiguous kernel memory allocated via alloc_pages() or similar. The latter such memory pages usually have a refcount of 0 when allocated, and would be incorrectly freed page-by-page if used with defio. That free'ing corrupts the memory free lists and Linux eventually panics. Simply bumping the refcount after allocation doesn’t work because when the framebuffer memory is freed, __free_pages() complains about non-zero refcounts. Commit 37b4837959cb ("video: deferred io with physically contiguous memory") from the year 2008 purported to add support for contiguous kernel memory framebuffers. The motivating device, sh_mobile_lcdcfb, uses dma_alloc_coherent() to allocate framebuffer memory, which is likely to use alloc_pages(). It's unclear to me how this commit actually worked at the time, unless dma_alloc_coherent() was pulling from a CMA pool instead of alloc_pages(). Or perhaps alloc_pages() worked differently or on the arm32 architecture on which sh_mobile_lcdcfb is used. In any case, for x86 and arm64 today, commit 37b4837959cb9 is not sufficient to support contiguous kernel memory framebuffers. The problem can be seen with the hyperv_fb driver, which may allocate the framebuffer memory using vmalloc() or alloc_pages(), depending on the configuration of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer. Fix this limitation by adding defio support for contiguous kernel memory framebuffers. A driver with a framebuffer allocated from contiguous kernel memory must set the FBINFO_KMEMFB flag to indicate such. Tested with the hyperv_fb driver in both configurations -- with a vmalloc() framebuffer and with an alloc_pages() framebuffer on x86. Also verified a vmalloc() framebuffer on arm64. Hardware is not available to me to verify that the older arm32 devices still work correctly, but the path for vmalloc() framebuffers is essentially unchanged. Even with these changes, defio does not support framebuffers in MMIO space, as defio code depends on framebuffer memory pages having corresponding 'struct page's. Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.") Signed-off-by: Michael Kelley --- Changes in v3: * Moved definition of FBINFO_KMEMFB flag to a separate patch preceeding this one in the patch set [Helge Deller] Changes in v2: * Tweaked code comments regarding framebuffers allocated with dma_alloc_coherent() [Christoph Hellwig] drivers/video/fbdev/core/fb_defio.c | 128 +++++++++++++++++++++++----- 1 file changed, 108 insertions(+), 20 deletions(-) diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c index 4fc93f253e06..f8ae91a1c4df 100644 --- a/drivers/video/fbdev/core/fb_defio.c +++ b/drivers/video/fbdev/core/fb_defio.c @@ -8,11 +8,40 @@ * for more details. */ +/* + * Deferred I/O ("defio") allows framebuffers that are mmap()'ed to user space + * to batch user space writes into periodic updates to the underlying + * framebuffer hardware or other implementation (such as with a virtualized + * framebuffer in a VM). At each batch interval, a callback is invoked in the + * framebuffer's kernel driver, and the callback is supplied with a list of + * pages that have been modified in the preceding interval. The callback can + * use this information to update the framebuffer hardware as necessary. The + * batching can improve performance and reduce the overhead of updating the + * hardware. + * + * Defio is supported on framebuffers allocated using vmalloc() and allocated + * as contiguous kernel memory using alloc_pages() or kmalloc(). These + * memory allocations all have corresponding "struct page"s. Framebuffers + * allocated using dma_alloc_coherent() should not be used with defio. + * Such allocations should be treated as a black box owned by the DMA + * layer, and should not be deconstructed into individual pages as defio + * does. Framebuffers in MMIO space are *not* supported because MMIO space + * does not have corrresponding "struct page"s. + * + * For framebuffers allocated using vmalloc(), struct fb_info must have + * "screen_buffer" set to the vmalloc address of the framebuffer. For + * framebuffers allocated from contiguous kernel memory, FBINFO_KMEMFB must + * be set, and "fix.smem_start" must be set to the physical address of the + * frame buffer. In both cases, "fix.smem_len" must be set to the framebuffer + * size in bytes. + */ + #include #include #include #include #include +#include #include #include #include @@ -37,7 +66,7 @@ static struct page *fb_deferred_io_get_page(struct fb_info *info, unsigned long else if (info->fix.smem_start) page = pfn_to_page((info->fix.smem_start + offs) >> PAGE_SHIFT); - if (page) + if (page && !(info->flags & FBINFO_KMEMFB)) get_page(page); return page; @@ -137,6 +166,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf) BUG_ON(!info->fbdefio->mapping); + if (info->flags & FBINFO_KMEMFB) + /* + * In this path, the VMA is marked VM_PFNMAP, so mm assumes + * there is no struct page associated with the page. The + * PFN must be directly inserted and the created PTE will be + * marked "special". + */ + return vmf_insert_pfn(vmf->vma, vmf->address, page_to_pfn(page)); + vmf->page = page; return 0; } @@ -163,13 +201,14 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_fsync); /* * Adds a page to the dirty list. Call this from struct - * vm_operations_struct.page_mkwrite. + * vm_operations_struct.page_mkwrite or .pfn_mkwrite. */ -static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long offset, +static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, struct vm_fault *vmf, struct page *page) { struct fb_deferred_io *fbdefio = info->fbdefio; struct fb_deferred_io_pageref *pageref; + unsigned long offset = vmf->pgoff << PAGE_SHIFT; vm_fault_t ret; /* protect against the workqueue changing the page list */ @@ -182,20 +221,34 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long } /* - * We want the page to remain locked from ->page_mkwrite until - * the PTE is marked dirty to avoid mapping_wrprotect_range() - * being called before the PTE is updated, which would leave - * the page ignored by defio. - * Do this by locking the page here and informing the caller - * about it with VM_FAULT_LOCKED. + * The PTE must be marked writable before the defio deferred work runs + * again and potentially marks the PTE write-protected. If the order + * should be switched, the PTE would become writable without defio + * tracking the page, leaving the page forever ignored by defio. + * + * For vmalloc() framebuffers, the associated struct page is locked + * before releasing the defio lock. mm will later mark the PTE writaable + * and release the struct page lock. The struct page lock prevents + * the page from being prematurely being marked write-protected. + * + * For FBINFO_KMEMFB framebuffers, mm assumes there is no struct page, + * so the PTE must be marked writable while the defio lock is held. */ - lock_page(pageref->page); + if (info->flags & FBINFO_KMEMFB) { + unsigned long pfn = page_to_pfn(pageref->page); + + ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, + __pfn_to_pfn_t(pfn, PFN_SPECIAL)); + } else { + lock_page(pageref->page); + ret = VM_FAULT_LOCKED; + } mutex_unlock(&fbdefio->lock); /* come back after delay to process the deferred IO */ schedule_delayed_work(&info->deferred_work, fbdefio->delay); - return VM_FAULT_LOCKED; + return ret; err_mutex_unlock: mutex_unlock(&fbdefio->lock); @@ -207,10 +260,10 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long * @fb_info: The fbdev info structure * @vmf: The VM fault * - * This is a callback we get when userspace first tries to - * write to the page. We schedule a workqueue. That workqueue - * will eventually mkclean the touched pages and execute the - * deferred framebuffer IO. Then if userspace touches a page + * This is a callback we get when userspace first tries to write to a + * page. We schedule a workqueue. That workqueue will eventually do + * mapping_wrprotect_range() on the written pages and execute the + * deferred framebuffer IO. Then if userspace writes to a page * again, we repeat the same scheme. * * Returns: @@ -218,12 +271,11 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long */ static vm_fault_t fb_deferred_io_page_mkwrite(struct fb_info *info, struct vm_fault *vmf) { - unsigned long offset = vmf->pgoff << PAGE_SHIFT; struct page *page = vmf->page; file_update_time(vmf->vma->vm_file); - return fb_deferred_io_track_page(info, offset, page); + return fb_deferred_io_track_page(info, vmf, page); } /* vm_ops->page_mkwrite handler */ @@ -234,9 +286,25 @@ static vm_fault_t fb_deferred_io_mkwrite(struct vm_fault *vmf) return fb_deferred_io_page_mkwrite(info, vmf); } +/* + * Similar to fb_deferred_io_mkwrite(), but for first writes to pages + * in VMAs that have VM_PFNMAP set. + */ +static vm_fault_t fb_deferred_io_pfn_mkwrite(struct vm_fault *vmf) +{ + struct fb_info *info = vmf->vma->vm_private_data; + unsigned long offset = vmf->pgoff << PAGE_SHIFT; + struct page *page = phys_to_page(info->fix.smem_start + offset); + + file_update_time(vmf->vma->vm_file); + + return fb_deferred_io_track_page(info, vmf, page); +} + static const struct vm_operations_struct fb_deferred_io_vm_ops = { .fault = fb_deferred_io_fault, .page_mkwrite = fb_deferred_io_mkwrite, + .pfn_mkwrite = fb_deferred_io_pfn_mkwrite, }; static const struct address_space_operations fb_deferred_io_aops = { @@ -246,11 +314,31 @@ static const struct address_space_operations fb_deferred_io_aops = { int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma) { vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); + vm_flags_t flags = VM_DONTEXPAND | VM_DONTDUMP; vma->vm_ops = &fb_deferred_io_vm_ops; - vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP); - if (!(info->flags & FBINFO_VIRTFB)) - vm_flags_set(vma, VM_IO); + if (info->flags & FBINFO_KMEMFB) { + /* + * I/O fault path calls vmf_insert_pfn(), which bug checks + * if the vma is not marked shared. mmap'ing the framebuffer + * as PRIVATE doesn't really make sense anyway, though doing + * so isn't harmful for vmalloc() framebuffers. So there's + * no prohibition for that case. + */ + if (!(vma->vm_flags & VM_SHARED)) + return -EINVAL; + /* + * Set VM_PFNMAP so mm code will not try to manage the pages' + * lifecycles. We don't want individual pages to be freed + * based on refcount. Instead the memory must be returned to + * the free pool in the usual way. Cf. the implementation of + * remap_pfn_range() and remap_pfn_range_internal(). + */ + flags |= VM_PFNMAP | VM_IO; + } else if (!(info->flags & FBINFO_VIRTFB)) { + flags |= VM_IO; + } + vm_flags_set(vma, flags); vma->vm_private_data = info; return 0; } From patchwork Fri May 23 16:15:22 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: mhkelley58@gmail.com X-Patchwork-Id: 892102 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94549297104; Fri, 23 May 2025 16:15:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016949; cv=none; b=nahlCNz/lLafHCI6rsWGKZOc2c92wNonkaOmmXxpG5JSVc+VFN5yIutuvM/Pkc3mKpM1H2hf+4tlGsLuHDocbY8esFyzSR1lQhDnj10r9QTYcVeqqfxX4IZtWBypmhXnxa51BnLC0MfaMlpGQ5GcSudYxX+k6J/5HoKQo4+qERs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748016949; c=relaxed/simple; bh=UqNvfT8UNcQF1ajewAq/dch5PAUIobvrkdEpLmAZ7wA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=c5zpNeFPHfSY/BQUKuwqHR2jDBt3X5kYvZo+Chiqd33Jaad9gne3BMI/xtu5Whgh7uHfN+yxKut1EsZoB6jB62C88+2wnDl/i9nGDOmH3XWVn58F54oaOKV42qkkss8ux3R4at1VS4H4wwgDZB3XWqRqo6Yp14GzPp3gy9a5OyY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Cu7XiHdo; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Cu7XiHdo" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-30ea7770bd2so155607a91.0; Fri, 23 May 2025 09:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748016947; x=1748621747; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=GNk2zZpC65xRherJZoi8fazJtKf8aShkVrAnPTjrn2Y=; b=Cu7XiHdoJy9Zr3DyJmFBzr7/ZWGBucsF/KnfVoOUReqlubC7o6HzBUSLeGWF3K2ZVm f2i9u6jkOVgnU8bntVWMX30O3mLH28sl2EhR3n7RoqP+qmf1c1ILoFK329/dH5rqHojl jEK4i2GHgvfBA29kD+/km+FfJUAtDfN1iI9Uyp4l1gmjjV92bSoG4WSD/rjxaOHOu9Vv UTSU6mwp/uE2cvkMWcr3d31jCZOM78kOpKL1Bup/uivjpS53OQjJ5Z49ebbm8Y0bRVqA VtxXhUJ9W6ScKXc9uRnRsj2e3dUh5LlTxIODDj3Je62fYFE6A1i+Kv0DF3h+r5d2jNYf s6KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748016947; x=1748621747; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GNk2zZpC65xRherJZoi8fazJtKf8aShkVrAnPTjrn2Y=; b=ZQZhapoMprdv7kyStv4C8JcjW1o1/nXwZSOc7z0m4bfeZglWoI+VpAl94r3L6XHq5Y fziFVYy/tTOT4/rB826CDiusvENIIpyv590dx9+FeCd/SapNpFvDisdLa1Rii8t+qY2Y Bm/4ttIMb4NIdKvG06SZSLtemTukPZ/Dfzeo3e2FatWKDypNA3ggboS0sDahQBY0lPn3 yTX/7BBxPf7+/1sR4WMfxU3baDLP6o/AjsFC9Ayg3t8NT/Eup+GriubPmQp8Qmy4oKVO tZZTfQqFd9KZMM+7KQKAxfwwx3rgKcBB6k7t0YSWUsOz/j/rRcT5W0/C0a1IkUJqIN/N wp1w== X-Forwarded-Encrypted: i=1; AJvYcCU6Zeo6gTj2VdQza/PGr0kbtiXTz0SWUbLymWuz4ZCG9SpndoLpsAM8hT7e4ByjU1i/miRULI8wIUEVGuOB@vger.kernel.org, AJvYcCUfTMS6keZu6X0izDgNi2Dk+FhihLpgBeZTIIX8aKinwbNuErmsvt7tUcxZNrPaOAXJKCwXZl9YdRXRtQDg@vger.kernel.org, AJvYcCWTVlZnEwuU/S+KhRV1NHrUKzfco2gJuP7UOa3kYW1ChDW4uLzySuUbVg4GFK59e2cX8Tbli3HmlODnew==@vger.kernel.org X-Gm-Message-State: AOJu0YzP9db3TlLAFVQQ1CY5N/S1V7XD7O2VOyrVi/x4rbVXfTbZ9jA4 g74y5/U/8d6QraiUOm+MwPfsCC5AahHpY6gNNiSRrYdmwu0NwfurS3r5 X-Gm-Gg: ASbGnctab+ht3+C0P9Wd2uKC0kMh8FEjjULW3mtvsL9Dfv9PtjRTYCfk/47HDWCR/o9 kph3Kwv9IHzg7fet5B8OID9q3H69z+Lzpbzr/QEak/QnbQSRgF8pO8ZyRdXgpoi5oto+ToX7Vrf SIh1oFPdYq4T+h24+G717aKkVqCT90nhjysb++5UqimZO14Uim8VpfNIWq5wx/yOufNEnCZVS6C Ywlb7Kd16q8sHOaY5PWFbBFwlhSTZYJf3qvhuCwR0TPA94iIHKUz8ziRMCHrW+cRmWXNEilcwq4 7W8VRSAVoomGq2GgNeg9wfao+KIfecoKprSbAkNCbGLitvK0RfBHDdO2wuw+UQKHxZPZ1KgZH8U m39V6TkQzWXSl/Ge9wBcQp1RYoPBt0g== X-Google-Smtp-Source: AGHT+IFx/FJsdG8AnNi6eg+BilBglUFlrj6JEqa2pyvzhIeq+c199ROzKQxdHjIHsfWSCrtByMxf5Q== X-Received: by 2002:a17:90b:394d:b0:2ee:d024:e4fc with SMTP id 98e67ed59e1d1-30e7d5bb433mr53256647a91.33.1748016946693; Fri, 23 May 2025 09:15:46 -0700 (PDT) Received: from localhost.localdomain (c-67-160-120-253.hsd1.wa.comcast.net. [67.160.120.253]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30f365d46ffsm7526565a91.25.2025.05.23.09.15.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 May 2025 09:15:46 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: simona@ffwll.ch, deller@gmx.de, haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, akpm@linux-foundation.org Cc: weh@microsoft.com, tzimmermann@suse.de, hch@lst.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 4/4] fbdev: hyperv_fb: Fix mmap of framebuffers allocated using alloc_pages() Date: Fri, 23 May 2025 09:15:22 -0700 Message-Id: <20250523161522.409504-5-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250523161522.409504-1-mhklinux@outlook.com> References: <20250523161522.409504-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Michael Kelley Framebuffer memory allocated using alloc_pages() was added to hyperv_fb in commit 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.") in kernel version 5.6. But mmap'ing such framebuffers into user space has never worked due to limitations in the kind of memory that fbdev deferred I/O works with. As a result of the limitation, hyperv_fb's usage results in memory free lists becoming corrupt and Linux eventually panics. With support for framebuffers allocated using alloc_pages() recently added to fbdev deferred I/O, fix the problem by setting the flag telling fbdev deferred I/O to use the new support. Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.") Signed-off-by: Michael Kelley --- drivers/video/fbdev/hyperv_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c index 75338ffc703f..1698221f857e 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -1020,6 +1020,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info) info->fix.smem_len = screen_fb_size; info->screen_base = par->mmio_vp; info->screen_size = screen_fb_size; + info->flags |= FBINFO_KMEMFB; par->need_docopy = false; goto getmem_done;