From patchwork Tue Apr 8 18:36:44 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Kelley X-Patchwork-Id: 14043537 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8854C369A1 for ; Tue, 8 Apr 2025 18:37:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B64E56B00DC; Tue, 8 Apr 2025 14:37:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEDCF6B00DD; Tue, 8 Apr 2025 14:37:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91A716B00DE; Tue, 8 Apr 2025 14:37:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 719246B00DC for ; Tue, 8 Apr 2025 14:37:01 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 93276C13F3 for ; Tue, 8 Apr 2025 18:37:02 +0000 (UTC) X-FDA: 83311733484.15.5D97511 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf09.hostedemail.com (Postfix) with ESMTP id 972CE14000E for ; Tue, 8 Apr 2025 18:37:00 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nIu3mXlE; spf=pass (imf09.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744137420; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sQx5kL2HMBRicxt7p/SiPvwoIXxU9EbXiMpn/Q8TNZ0=; b=chYg2w9PCP0WwsUXFjiFbZazff99CPzqCDV+ApL7QB1KQubtP5RxBoCMguyZRSWX1Y1txz pgQmksOx3VuCZLrLujrDKNkwfsg9M2zUwPMADAwpTLkVvUc4a3fHS6cYZmoPXtikSq7eWh 4dcTY5uurkXE0iUNt+NDzkekrKU4O+A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744137420; a=rsa-sha256; cv=none; b=ItCDSCiI4za7BbyOQq5NR7ie1tWi60o/bqS6WTKP8LOL7McfrQJrOOw2D6abbPj0eOLZ5K x2Jfsbpq3UeNGDBEPouxMTL+vgLr2mEBKqZ1shsSGKrk7adLesUzlL40pO/rLtGb+MsBPA o68ZAbe657FMv2KopjjyNMq8ltkpC0M= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nIu3mXlE; spf=pass (imf09.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.179 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-7376dd56f60so4366369b3a.3 for ; Tue, 08 Apr 2025 11:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744137419; x=1744742219; darn=kvack.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=sQx5kL2HMBRicxt7p/SiPvwoIXxU9EbXiMpn/Q8TNZ0=; b=nIu3mXlEkhAkKKVcOKcyqi505+FXrxylDeTsM/au/0+vwEAgfUKffAR3p3R96mY0qo Q542WasZBwMFZ3tVXvRSuhA1I4BdWz7LPwZXeQ5vadat2hYdM1g/yPRJynL7Z7hFjJfC h+WL7/l7rwiZJkaknea2w6Nv4TZhLSgjZxfvSqmlyJlGRWhJCBvVw3EBSA+2kb5C7UCV N90YyGsi3FoYA0ocTjDykq6/u3CNv8WwcQRv6FKWItu1kFQEuBsTwzl1ZGhYoznmMTYd rrqm0fnmMxF1Mf72YLA7AVzGeoelByf8LyJafP37E3c4oCoFvRntye8WTZ9em9RY/5md awxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744137419; x=1744742219; 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=sQx5kL2HMBRicxt7p/SiPvwoIXxU9EbXiMpn/Q8TNZ0=; b=R9s2sILPPxFU9y9lF64aEmjjOwz6CxlYYz2lGB/OVj62SeksQ9+sZzmG18zX+LPf2H Ut4HaufY1WOawjKOLKgEvmb5FO9J2jufxU2zS1T579QuVcjepLjFTM7t1Ww+Q9OUIeUX UDQMSFMN8eKwhPM+UqrKLx5SxP5KFTvmk2P/ltqHf1WSJXUuXFNBkGX4yXkKYwhqs3aw AqhB5Eb4uU+dhQwhHQMJQvFiMlzIPBQ4umWLlZFP+fqkm2MY8JlYNX4hwvqVMPn5uTg2 rKTPBAmUkpFncshfT2EsilUGCnV8Qi7mHQT2ojTbUqaFW9YKdrz3qnL03A095suRY4Rb aUEA== X-Forwarded-Encrypted: i=1; AJvYcCVFG+aL7ReORpBl40mMnZifXdMlf92fYoh073Bngdywv9U3+DQoC3irXam43AyrfsEx3G+UtDimlQ==@kvack.org X-Gm-Message-State: AOJu0YyvHWknh7lCM7Z2qJJ+XNMtL18YLfv3TWCmzp7xleN1zZyjVPye 4nshw3Yot//WOQqOE46g7rCmo+SGlJ4G9BonGwWPQmkZcGHJogdy X-Gm-Gg: ASbGnctYRf5jU58mb/lL3/glAh6SpYn6SIBlkoO8L78cvMuw9Nk0VoE/qne6Kp6XVZe 67q72HUXjnIDXmI44RDkQ0pwc8pYxEdklwWomS/FkzT5zreazrUVinD6VF88Q30nNq63wgexDMn 7QiTNCf2rpvmFpud3n3dfX0JAtRXajxllM7nKBks638WF8WjRgOgj8GLAgWWb96OuaOXY0/miyY rJ/7U50F6eQmaHSOeyxLUq5nSDmMJFfUEf8Wxaj4iywqsTOOhjzVRotJ94pnigdTFSlkqyyoss9 lXtvCMgF2NXnKpKq3V0MF2X25OJ/4bS0PPM+4uny8OWe/OFAAkbDOVsPBX8tHLPN2ANTENXgLrc 49j0KFkZQvOvtuMoxf/SP1+Y= X-Google-Smtp-Source: AGHT+IEjwArdNPWWYuDFcDmnKKWKrgBr6kLPXpKsC7dfbpRyYKqI8aTmyy8lbfzaFKrF/1/S/MR/dw== X-Received: by 2002:a05:6a00:1152:b0:736:ab21:6f37 with SMTP id d2e1a72fcca58-73bae30912bmr152104b3a.0.1744137419397; Tue, 08 Apr 2025 11:36:59 -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 d2e1a72fcca58-739d97d32b2sm10960469b3a.5.2025.04.08.11.36.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 11:36:59 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: jayalk@intworks.biz, 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 1/3] mm: Export vmf_insert_mixed_mkwrite() Date: Tue, 8 Apr 2025 11:36:44 -0700 Message-Id: <20250408183646.1410-2-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com> References: <20250408183646.1410-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com MIME-Version: 1.0 X-Stat-Signature: hwwnf1bcdc8j58qsr764rj6aj78g763j X-Rspam-User: X-Rspamd-Queue-Id: 972CE14000E X-Rspamd-Server: rspam08 X-HE-Tag: 1744137420-994674 X-HE-Meta: U2FsdGVkX1+btBuLo5GYl8dd/yVSzEXboWdRM3RrK3jQzZqZxbohL795LBk8kJAsm0yRHlvfAvU9S2J90896PlLAw5Cb+sldiFqEs2sgIxBS4CC+vRTqja0q/zUhzxF369/SR7PDuP4Plkz2Kr4sDY3Coj0mcKKuZ+xrkCuvm6UoXxzrwuIY6f5anKNdmvozY3FZzvz0o20tfnkD5md62CWcP/F41xrYyAvpVYXR0y6WgWf/2JWe30rIYd5jeYYTwuD3z7RFcTfA0h8JBgZqI7z+mrfNvawn569xvwwFVPLffYdY2nWiLKJadIWOHn6kbi3lUTwDgcQ51/+JuRsmV9firtMR8BrqhOW9YAalOGnK/RtGyaa32m2eeAFmYqRNxu5OC+oWqsEofEJJS8oEWkf5TTqJFoc+W+6IpOYv2Y+9h8bXstnTd9Drp3FdLQ4kwPQZVlyv3qkPe4xN+LeRgJAgd4Om9B7cX3OzaHV5nvMGC4gCLDPPWNsrGuZ2lqbhWXM7oqnRfeoypbMa4TBgFaVhVwS6fDtaca8bfQ1qJUoWTzJ7LLvVdpbNFc1VllTtp+6upTA2F9oZa18/y50PQXk1ocrwwRhCD33lQHtjGMU+4TuBMaNg7Ffg1namr3VIc2e3XqNrUKQ5cQNcn7Gd2Gib9by4ZIhmRl3Uk1tKmLA1PoGkOl2YTMoRvNhIid9zGtAjL28ox0R7cVzsYtfX6vs/lqgzz0dvHHxTbFKWJbx/UWiFLpenxXah4Rf4ILlcnhp9pHuYTo7iAY66YvyZFQKgw7uNTXw9eDr0czqtlARDWFTZ+61pWNe5urqGQiUJtAuchvRuzTpb2i2CpKJ4lbTuc++ex6X5CJpQ19KGpe06wjdXy2Je2DNisTct9ocn/MB5hxURsYJIpQodRvCBM2/7QFxOvHyU7mhhM+oOfXGPmWf8l9SjDjG6y4Kt1i7TDDARe1mS+UPXWzalzxb wDPdQp22 GNzJ47IjFsjGhFlyUezaqZpWLFdsYtTztvniDE57bQ4L5vST1MJRqTYQAqTDMSQMvYFavCrVjGXTWPdMx/ylmK1mpDjyj+ZlkfsaKSyHpUZZHyei1fCCoXLBIe0LtMO4nCPlU64KSvpNh3DQiK/Bx7+Liseg+IyfHYorWHOpxJzhoSaCBg7wIrcybWH/0cCf2BUq072i9qOxR4tx947jKYXJ78aCgsoXFUYkDRzB3+cvvsiEGUHNE1OlJrZ0QyLs0exHU6UJz/WZMoW1+rV/9FmTn+gSmI2CsFGQvZ6we1vwdaqySS59hXA2CNS33lHxpHgAQZ3I2/8McdRsD/EOjMMTE2cHDKhc7sjSV/42j/0Pu7p+18L4Q3XRujFKF0hGHdouKQ/MqRxK3SVgU3jQ0ru8QYcuPnzh+Z2jt59OQxYtI08SBJfqeJTMMt/EiDj7y2/FZx0tTynTwAmMH7Sa9/As8jnzWSVueKuwvsuGn87uCPui48kU5f4rb+i7RrAsw39O/us69iiUogS6t45gI3Chat6RZUnng8qNLRdUCF38njrIefoOFh3h8VGmkOjN8xdkZjEJtPyrqx+oQy8wMHhzXgKQs9Zan63qlD5oZflji4xK5U10Qwuu0YhYyoia7uHq5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.005976, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Michael Kelley Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code, which can be built as a module. For consistency with the related function vmf_insert_mixed(), export without the GPL qualifier. Commit cd1e0dac3a3e ("mm: unexport vmf_insert_mixed_mkwrite") is effectively reverted. Signed-off-by: Michael Kelley --- mm/memory.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/memory.c b/mm/memory.c index 9d0ba6fe73c1..883ad53d077e 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2660,6 +2660,7 @@ vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma, { return __vm_insert_mixed(vma, addr, pfn, true); } +EXPORT_SYMBOL(vmf_insert_mixed_mkwrite); /* * maps a range of physical memory into the requested pages. the old From patchwork Tue Apr 8 18:36:45 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Kelley X-Patchwork-Id: 14043538 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 795ACC369A6 for ; Tue, 8 Apr 2025 18:37:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21B376B00DE; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17DBC6B00DF; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F12966B00E0; Tue, 8 Apr 2025 14:37:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C0B656B00DE for ; Tue, 8 Apr 2025 14:37:02 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E9A7AC1405 for ; Tue, 8 Apr 2025 18:37:03 +0000 (UTC) X-FDA: 83311733526.14.EDD94AF Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf24.hostedemail.com (Postfix) with ESMTP id CE43C180003 for ; Tue, 8 Apr 2025 18:37:01 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mL7dvnLF; spf=pass (imf24.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744137421; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yaU+5633ewJo+47cjHg1WFMmmsE9Nb6gzhZCIjFmnWA=; b=09nJiygJO/mvevyifW+DTmWLn87S1n9O7JwbQvL3pg0Hax7PoxyRpxawvm2lAzHTop1rIZ 4umY7zwL8BtL/WhlQOy9g9zZBgSVEyNuIjwPt90nuUn1Uf2+flpjgnnQvA8SJNRM3U4N1M Ex3DptP+I6FG3iBcsqEXjiOIzj2RhFo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mL7dvnLF; spf=pass (imf24.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744137421; a=rsa-sha256; cv=none; b=th0M3pAAzqLykm8ZJfcdkxCyogkL4aQP1bPn/zrHm3mCoqJg0i2/q1mm3skyqD007AtldA tlaPKU7m7irCE28m0abc1Dem+iTyrUFLgTn1EZqR4dCvepBfpr0CsnZTAZdyTGYKkopaS7 5uYpdpqwkOQc7LyVScJMBjYTjmHl4IQ= Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-73712952e1cso5496104b3a.1 for ; Tue, 08 Apr 2025 11:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744137421; x=1744742221; darn=kvack.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=yaU+5633ewJo+47cjHg1WFMmmsE9Nb6gzhZCIjFmnWA=; b=mL7dvnLFfeK/opNgkLnhIW+QBLuosKHgfCr3iAG7jAECH9BjovCo08JlmgH/nFRqmL +kyBXQE4RFJnVb3n2+5xHbw8b+CXZ12FAiexm+AvqxIHLYCtvWy0WP7Jy94q2ffzY1Xd cA8OHwVZKN5oH6RJdYGOzyjvSFUxBX/uKMxkWyJCkMh9lJF+X1lx2DUkbmK9+VtKU+Dp GEoFKQVInLpxuojf2z4OEA8AZkV1zJTdcYIdgqaHNPrDmoG0EIP9g+r2q773gj8cYRPM fAYdrexjj2qbS2vdICmX7pGV4s1DM87oux6LrnbEjKk4Xjw+DWpFw4+F0JXDXzNvmUcB gJ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744137421; x=1744742221; 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=yaU+5633ewJo+47cjHg1WFMmmsE9Nb6gzhZCIjFmnWA=; b=tU5+tuH+mXv47VcBJvGvgIgsN3qb0cW5OahUTs9kmj8OKk6QTi4G4LVUwW/INKYVrg 9V0z+S4FQS64Lkd9zTJyhKMlvL9hV0FId1h1gRIAaOzLmQUrwKPwFscHl7+SwfLxQGGH 75Ktl9V4x+LVwMY4mG2MMXTHIaXRlGpWVSYTtqaZvV1JQRWk6OQsZtm0Vs1y+n9PXZPb r/WJtrsHwgZQA1u6NN+rV0ACYM7IlfiY37VRWszTlftahD7gMkF4Ko4pvD7t13//q5pC 62M26jLDU12HQ32afraOcZPZScYvvL2YCX5sEn1R1JPdkH5TBKqstNyjarVFyZ8VAAU8 9s1g== X-Forwarded-Encrypted: i=1; AJvYcCWSGADI5SrRfxXR2KvCdXufuypDbmFfFcJ+N0RHPUEZPhy+TJH2AtMMtBpET6WySUStoK//B3IU/A==@kvack.org X-Gm-Message-State: AOJu0YwExbwN3TQ+8oh8k+7bbXMbn/1qtSQD5ThQ889N8t+c3hSi3V7h Iu6RhVlx1TfUKm82S2/eZQiGFBOwmVbGlQk9bpKh1jlm6JdaIdTU X-Gm-Gg: ASbGncsxighB3QgdqP+lvsN6ejCjLxuerWhjl6+imXF5peOO5ItBQYLph3SmtECQvhS qqcsXh/qySZQA5ZYV61fPLgDllHu//PZ2aBp6yNn65EuodgT7p3neAiPTH99cVOGSsDfdwrixA3 xt94bNafIj/Htabsn+rhLgJaevf3ENuseKwOEq3Q0FmacAR3316YhgGkGB6R6+bWOknXCkAdobc RHCAC2Axp1jO8187ApcciDS6l1+ByDc0oxxMszwYTXELRVk/VQeWvHFnPK1FU495V3OUOdCl5vx OUzw63HSediMerIGDgJxwylmKii+KJ9h9HWKc65iMJ3aYYd5V/fuYDi8jCsZQGUDj5o7iMHmmjZ 2E9Oe0XDDxnrrP0WbbgumEKw= X-Google-Smtp-Source: AGHT+IHVHsepbXorylQC9VxOWgtbUH6lFwU2otdZFrXXy0fXuJkqEdBn0S7PNfOtArRZ51249Vrk0Q== X-Received: by 2002:a05:6a00:114f:b0:736:2ff4:f255 with SMTP id d2e1a72fcca58-73bae527668mr78501b3a.15.1744137420544; Tue, 08 Apr 2025 11:37:00 -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 d2e1a72fcca58-739d97d32b2sm10960469b3a.5.2025.04.08.11.36.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 11:37:00 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: jayalk@intworks.biz, 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 2/3] fbdev/deferred-io: Support contiguous kernel memory framebuffers Date: Tue, 8 Apr 2025 11:36:45 -0700 Message-Id: <20250408183646.1410-3-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com> References: <20250408183646.1410-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com MIME-Version: 1.0 X-Rspamd-Queue-Id: CE43C180003 X-Stat-Signature: 316mxmb8c9sffrsgutizq7cpon5s4gmb X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744137421-871177 X-HE-Meta: U2FsdGVkX1/36el3XrFZC62YPUu8dMvrI3G9szREIVTNjphCuVaizHITwlbB5L1Ubu9/Y8mBjRP7BV683cYRNQvPiLLaIbsqU0c7noTdr+f91EXGQE+JLax2gO/maj5VTCT2GZhPcWUi7vFwFojv3l3p5SMolyRmbQJ/WsqypisaybajX9GT32Qi+8ysDpn6BJMMuHx5lxKYzp/NIktfyppofr91V4EW4b8UeskbshV0flSenJ+Q0uMA2spiMtqvMS7Swu8zvfWvXRz8CbgJBKhjAC6VFEMrHH5vhtjyKI7g8NDOTMX2tWx/vKFb0KTH8dR0GwuWYrI/7RhSu2BdiXu59FHa0miCpItxEGImgKnwWW+CYHaMlMYWj61Va9m1LaxdNHFTMXXdUfvT4ZktyxgsZcwUOj5EIrt4aIVLj9k4FIR+ODrAq2IDbj3v4rrRNPCH4paC3MO/v0XVnVz6U4ngaE/Lb1RhY+G85BAdli5Kas6ERYnNslzaO9SZ00lIB9G09AuGoBIXwXkQuPa6ciRAaui8WtssI4r4Cd0/8nUmpOYeMV8aja6cjOsyyX7r2ZrkWKvuSHWotr20SRoD1KrdiqWMtySHWleGu/TT2K/ql43U5VCxnF2Exe0D+j0CuYzlYNP+l08m6N909h3+4q3RhNdAYZojcNXzTOx+xoYPGUVAoYRXbVOzTJc3tl67Ap7gTdRPRoj+67OGzjO0KnJaKgfml0A38bb1zMcejVLtBqTUsPaxtDWrD/kWke7e7DqfK1hJ1dvM+t4mM7vu9Nu/3My2ooDrT572k01osGPpXizG7VE//FWgkczzMXm0EcTaC2L2HlCTjFD80pjVnoOjziPuRbv8uqWxggzzGEjXZHtLHHBnG5iw7vgPrp17IUu9AIkGXeCqncLJ+qwC0m98WOHxgFMhpT8jps+tQed316qAgUqY0DFsf+bBm39ZlmLXTq0DkaELMbK/s8J FMQkM7U6 YExiaH3m7ttIl5r4HJDm6874wHepj5ghynAY84KA1E5IbdzIB8PZr95vfrWmvTH6G/lyqEymIgCidoffyDQSSw5KFtv8+ghv+bPDEP4TKgZw9JQW4YkOKzxf3j3jBgr8n8Yc3Cq3+d057JQu2FWSMqLRAeWm4WaS5DNRhlNqVL6lycSD65KM5JKm1jjtDRa9MhXnN69tSuzSGidaRgedGdJoOC+hKMOvK7IjYQBihZMK/fT2WAMcVsg2UwXcUHQ8E2Cjek35J5JJks1MCj9vrmnuT4qrwwlzxEWqnM4eT2HAR+bcYWtKrMQGbDf/nIqeS+zF8K4MFM+Tu0xpoBP3/hcbxqOa/v3iS5Plc2ch3WXn8BkrGxMr1wwIPEZDgglCzoOIlGSByKDit6sEkNULjfE1Mf8Mc3MJl4eMabMsjeoXfV0wkPNRfSzyrJ118bHUx8JiuKCcyV8qqH1L/FfeLLTECU+SHK+mpIT1zYuKrjpPb0FelhmNdop0REOtI8h4qZ3AZJsiHLh1m3Yx7oJtH+NuxpuyCnqi5kOmHkgdadvSpDAueto7Qhq+8oKliBrY26Dornp3xh8CW4IquwBJ6iL8ydQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 --- drivers/video/fbdev/core/fb_defio.c | 126 +++++++++++++++++++++++----- include/linux/fb.h | 1 + 2 files changed, 107 insertions(+), 20 deletions(-) diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c index 4fc93f253e06..0879973a4572 100644 --- a/drivers/video/fbdev/core/fb_defio.c +++ b/drivers/video/fbdev/core/fb_defio.c @@ -8,11 +8,38 @@ * 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(), kmalloc(), or + * dma_alloc_coherent(), the latter of which might allocate from CMA. These + * memory allocations all have corresponding "struct page"s. 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 +64,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 +164,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 +199,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 +219,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 +258,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 +269,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 +284,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 +312,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; } diff --git a/include/linux/fb.h b/include/linux/fb.h index cd653862ab99..ea2092757a18 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -402,6 +402,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 Tue Apr 8 18:36:46 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Kelley X-Patchwork-Id: 14043539 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15ADDC369A1 for ; Tue, 8 Apr 2025 18:37:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A80906B00DF; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E2E36B00E0; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80BAF6B00E1; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 54A966B00DF for ; Tue, 8 Apr 2025 14:37:03 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8CF511CA1A2 for ; Tue, 8 Apr 2025 18:37:04 +0000 (UTC) X-FDA: 83311733568.19.4B14C39 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf21.hostedemail.com (Postfix) with ESMTP id C735B1C000D for ; Tue, 8 Apr 2025 18:37:02 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UJJoI5fu; spf=pass (imf21.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744137422; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GNk2zZpC65xRherJZoi8fazJtKf8aShkVrAnPTjrn2Y=; b=AtgZlRVNlwT5gcjoQCA9+h8G0aWmokq6ZqZc1q5XyAbc7jsVzyIeX9tkCjhum7Jh2wt5N4 E6SvMlBTPsr0DQWlJ2YlaVRQWjAtZF2FsOr/gZnnPz6Mmwc3fXYA7BLvVcyK12Cl5968Pl 1j9HZMNqDDoixYB9Abb0mXuBuVZupJA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UJJoI5fu; spf=pass (imf21.hostedemail.com: domain of mhkelley58@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=mhkelley58@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744137422; a=rsa-sha256; cv=none; b=6rerlIl8eA5rjHyFjsBUiu2bARCU6fX6gXjNiHlFipHbsyfaB3NrLvCFz/5Y78jhVIX7u2 8dI0cO9gk/A0FCbdpKs4a/Kq5ub38GcQ3fi2hy4Zmkn7xe54/1PgSgmt9IXIUyVxs59Sk4 1mN47QlV1nnczOJgCx6NntMCzpKHCQk= Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-736ab1c43c4so5768723b3a.1 for ; Tue, 08 Apr 2025 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744137422; x=1744742222; darn=kvack.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=UJJoI5fuHL/jlDk4gPHJkspoglfZ56PF3Kpw95BezSxzoPKfJ2uVEuMET+Oz6RSglI qmav8lK6jKkESnw5dcn+7kbB1VtshYYYlycstES6+koFvHBtO81vFM4VCT+cFaDw68rV csF9MhHE8ulrjzoTHLcWAVJAqjF1thPwveOnZyKlOv3+XtcdN5pCEI5r3yPuEaTrDczC 4QP/C75LIoETsnxcctu2e5iZE57yzW6LTS+KX2/OHTXzxO6ljrrFp/De6IQotCnnjhUY jPiIUDYdq+Jm7syqAaGeHwmT2CHJDN45F8Eyg2YnrLn71X0Y2eTSqQNs+yid2yHr3ePr jWRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744137422; x=1744742222; 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=P4o7VFjHi0Xm58Y5GPG2kpDFw9WS4j/qoU7rFaZCLZi7vriUzXiwA3W1KHpji2bFph 1KoRCC/cpzbskpZmRjulISxE4qttUjA//qbsIKRlehr5BrfbOZFPpn//SoVSt9hogLjj Gc0ogGYPRhrM0BXwL9i7PlQNJUWwkd3UmtZhuSQWDXrwxt+lmxQMwsfTIwc+u6XwndcZ aEFwSicxIVMSJiGQ+vtS6rIBmrtolH4ujBLyYWEMmTxX4uxp2jYA/Z8Llf36K81HTBx2 ICX8VD0QxueNOelzGO4PNL8SKSUsHmn6lUXSCPl1pKDp0vpBquj5WXokyCfKY+AMNI/t d/Vw== X-Forwarded-Encrypted: i=1; AJvYcCUXtSYR0LCYMi/sbDcoxSusNbxhajIj0Ed/v+FfiifWzYUr9NtY6X5ifZiuCRQ7fp9ag0zZI5ZAWQ==@kvack.org X-Gm-Message-State: AOJu0YzaT+Ckh15W/GY7A2xqvMAKRXyYAvSkEJ9956sTq8wUZ4oKTgRv omHzRutj33buRatcu74KDSUmloV3amsoyOD8feX74Q7P/xQIPWyC X-Gm-Gg: ASbGncuia+A9InIM87dAmWEMMfXf4Cbm2AUSWMn82jCd7r3xukVPHIzq3VaV7yZHYp0 Eqn3yLfXwt658OfSeC3QZciNtFc/nsE3zpEtcyGTAuQii6XHwP+CXVkEndySmNhAz7CdbbvHHMZ 8/ZKeLNO7Lwmat8P/GFXNb0oRAvRpx2NB788bbNNSnkQw1+C2mWv3pwKcR3/+7oZE7lYHJH03gX iLS4yR1J+joZ1kihdti2fnkHFhYs7ghK929uFkxeKYFenYKF9pHAAATI123Oiaro+r2duWKfCOV qFQXlSiNbF3VWBgW2LM1Ejz30oxe8mtFfHqsVYDdb3rZM647cOCIJRB3JEarNNWlE+0JzpdXDtB /BgoVQdWlQNIdzfFKkuEcNBI= X-Google-Smtp-Source: AGHT+IFoxxArLlbdFj00rZFAC5VSPOC5ZnT2KxxJEAFIcKSD0E+nUXdTHUx2/AnLXQqCMh8+l9gjPg== X-Received: by 2002:a05:6a00:2408:b0:737:e73:f64b with SMTP id d2e1a72fcca58-73bae497469mr99517b3a.1.1744137421614; Tue, 08 Apr 2025 11:37:01 -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 d2e1a72fcca58-739d97d32b2sm10960469b3a.5.2025.04.08.11.37.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Apr 2025 11:37:01 -0700 (PDT) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: jayalk@intworks.biz, 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 3/3] fbdev: hyperv_fb: Fix mmap of framebuffers allocated using alloc_pages() Date: Tue, 8 Apr 2025 11:36:46 -0700 Message-Id: <20250408183646.1410-4-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com> References: <20250408183646.1410-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com MIME-Version: 1.0 X-Rspamd-Queue-Id: C735B1C000D X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: urgtcyty4g4kjfz3f5srbcuwoifmaing X-HE-Tag: 1744137422-422906 X-HE-Meta: U2FsdGVkX19+Xbt6skDeLasiqEIOaTQOkjjpy/8EJEf1XL47BnCpyCSguSBetuRgWSK5YvDZmLTU+07DSERHhfWQEZUNadny/zqA7M6HvvRUL1be+UZhKwvrtDl/IMtYmxKVpLuE+VOxhSRH0zV9cKGhVX1tZ0j22qpSXsSpGMM/7z7MxiKt9NLuHKWSEr2qgOoBLDeHpPLZqURvsrQ0AfJJdp0IgqhCHNCmMo19e3naO7qXPD98mq7uYrDDLhOznz5hRfkAhYE42W9I9GvI58D04N3ZW/0UY6DuJhcUrmO44rS55KJlcOe7KLBaCi2W9sUxDtcIlR34VVec7inx+SFnWYmgRhbn12Fjy30mD7CU3qJSjUZ4Ly+72ypK8aMdPYX4mxesQTcN2jFW3EKDDOzSrEnRL1XFV7BOOsPK4F9wWutFcXuo8Jc38XClZNc5kjr6QiQxbmwDestheXpS/V9bCS5FuRGK1WPChVjcRWLjvz6ERoiWXbBuMLjRQycEBeKPphEWgUa6HFfCZMwXmDLpNar7086iuPrBhsrDQGW3N/S6wHEF6aodMEiZ9Gx4LuEOd38Q8RE+Z4ZwpK8j3OtoYG3wNY8y9TFc5Mol86Iy2JX1D3wgcmTIaplT4nUSDOhFZJ3J2ic4XyZIS2vtoOHeek60P537k+ugHs3GP0H1p0yLjhYaDO6jTrsVP0aWaWSLSChft+dwHW0IMQLgNqunWfhNuYaLFU75YDwJPjCfWr0Q+GQgXInKa/nhhXERSrNCgnoLeoeN4nO6BkW8vKJnk9tbUxSQ49sUheISLCX2hFx3Chw2zfI9+Oj0KQlK+NhSkpD72RP/jUdZQOAn2m8VAk+D0W5GBHIOF74/I+9Q+IhiOLmZB5UE1cVx46qlIB7JlOsPdkvBry5WToQe5nglh4Pbq/HLnwdfvmJtcoksPUKfxJDM0OnH7+XrLTsFZY39djqa6WXH4cv1m0z JgKbUo4X msvZwu0SAmxbgbuGQ7Te+ecv0jIGRJwIErbG3s1e7tSIqCct8JgwRaJyq60MWqAyDYY86HjkeeKS5eTaq+TtwhXH2MWcT6Val6QkbCkMKNg4OTLp2cjrvAKyy7bRA8U0jfFsuOp9sSzFfclgjBM+SZVwL6vDJ/dxmUxZe8PvMIOSUHHLg9uY9HUnrI5k7uPeMC0I1OsxmSe+PZNAin3skb84GiwEOgQvmR/3k X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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;