From mboxrd@z Thu Jan 1 00:00:00 1970 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 E5F5FC282EC for ; Tue, 18 Mar 2025 08:33:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD64F280002; Tue, 18 Mar 2025 04:33:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C85EF280001; Tue, 18 Mar 2025 04:33:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4E9B280002; Tue, 18 Mar 2025 04:33:37 -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 9803A280001 for ; Tue, 18 Mar 2025 04:33:37 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7412BAB246 for ; Tue, 18 Mar 2025 08:33:37 +0000 (UTC) X-FDA: 83234008074.03.C88E5E8 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf21.hostedemail.com (Postfix) with ESMTP id 6C8DF1C0009 for ; Tue, 18 Mar 2025 08:33:35 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742286815; a=rsa-sha256; cv=none; b=biQUt5a5dCKINbTspZhGHr32PdIhGu6tWHE5q5qlK8x6EaiT6idO3BJW8L258eXEpBmg57 wG+zU3wkPYVhD0r+vUSeWtRDSzXYX4iC+TGuwqcr6NfhM1eWt9ivkGhx/KSxaQeXQ5gc2C jWrM2MlD7NtwkuaUn7mV17H2tMIah+Q= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742286815; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=DozOXwpYqouprL3l6aCjcNtNo4CCOLduSvCofGmAvNE=; b=cz7SqYSivDf2cyzBMJQxWYideA992++ALu2/xrt7U+sZtk7331F2c0ud079RQpN95HsA/K 49mSX4Ed08q1RvdRV1A4vffHjZ/eg7+HOobbD+90PBLX/zBG3rIcSVYItA3Ajw3bAysUrI 1Kp4vPf8SxL/e7xHNslmFS+qQ2sEV3s= Received: by verein.lst.de (Postfix, from userid 2407) id C08A968AFE; Tue, 18 Mar 2025 09:33:30 +0100 (CET) Date: Tue, 18 Mar 2025 09:33:30 +0100 From: Christoph Hellwig To: Huan Yang Cc: Christoph Hellwig , akpm@linux-foundation.org, bingbu.cao@linux.intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, opensource.kernel@vivo.com, rppt@kernel.org, ryan.roberts@arm.com, urezki@gmail.com, ziy@nvidia.com, vivek.kasireddy@intel.com Subject: Re: [PATCH] mm/vmalloc: fix mischeck pfn valid in vmap_pfns Message-ID: <20250318083330.GB18902@lst.de> References: <20250317055304.GB26662@lst.de> <5a12454c-16a1-4400-a764-f49293d8dece@vivo.com> <20250318064805.GA16121@lst.de> <5229b24f-1984-4225-ae03-8b952de56e3b@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5229b24f-1984-4225-ae03-8b952de56e3b@vivo.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Stat-Signature: hkkrxwzgrd5ecnjw3gk7mcr9kr3cdtf8 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6C8DF1C0009 X-Rspam-User: X-HE-Tag: 1742286815-835727 X-HE-Meta: U2FsdGVkX18hWAWMq5F7v+CjXybQJZ2E3/g1XToDM1+MJwd8oQzH/CoV4Bq5NRqxc6/DqwpLaP63FcD0Ms2ndHZdaPOMIKmngceXP49iJfH1KoUk8WTrKBBEzQ7B8nYZFjdJCq8tRt6BNG3JKAx+hchqD4aPx/UHLk17inokCIqM1gKwNNJ26dot4ehYTiTJBVCxUKcm1kmAeiv3yJ8cgMfv0XbH8RBMcVIczQNy/NW7DQ4PJrfYCrZOEQM02bs+mdQwlw7NHgxiwpbepCalT/yuC/lqluF2KVTuSbT0PHIgRH7h5PayTT/5R5p34HqXk1rlIquqrydROnFlShaR3pUSPq0dgcyoTL3FDqg/40xpvh00GWQJgGdTaBNf41MspyLAsA7BCN5OLmTdpEFvzZ4c8RRDEqvp0mmbckBGFf8wJ7J1Wvz4rrakDqVGm0Alvz5PHP0Gv+Qq9gtx/XAvv67h9tU45MWT+S5m+qJ3zPzfNmYlvoNOyugb8edv32NYwoiPTH4NRYZ2Y/T3oL5EQPqGPN3D5B1Yikfxqf5eCTQU3LRpyTWJme5gYCtzsj+7Jjmb9khE9/rpYSTlHjX9MarwbKFFCdJot+06B8C9ttZqV4z2KkmWtxS8L82vZAxroRjCZbS4b4iWe5O1CSulLVdlqyKvQgrrvR8y8w15yfeW33qTEYIoAnrauFgp2OmgzpjH6CJSzZ/NnIALE6efp39dG9dPPFzMk7yyLOwJ7L2dld3wB3n5gZcftBXsDe+fJDHx7JX8E+0qDBQy6EqYrSf1913AjJTdsMTkSaCdG3TFhCALvR28cIgmCRp2RNF0YlSHqSCzBH+4N8MZXbl4sVk7i55bsifHCwSHKxer0HHiYUccPxnkEYZGJ5z/BIKiGSrOwZUk71QghMCkNl0xwooT0LkrymIZ5gEAPkvxpsZZZWgfnSqQmmm8bX/pPGhnzzbJPLYSJ/+nIu+0HOP 2T0jITE5 qFylU4iOvJMX8wnULNwyzLSGDtahwWGo1jS+JOUx3Dj1DRy0NWKyZ/jgdH07JnhWM4tUIkBJpBrxlGh/pyY9kxcvvhU4EhT21p2vCBctKsG5QV6CWjImudYCX7w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000395, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 18, 2025 at 04:20:17PM +0800, Huan Yang wrote: > This prevents us from properly invoking vmap, which is why we have turned to using vmap_pfn instead. > > Even if a folio-based vmap is implemented, it still cannot handle mapping multiple folio ranges of physical > > memory to vmalloc regions. A range of folio is important, it maybe an offset in memfd, no need entire folio. > > So, I still consider vmap_pfn to be the optimal solution for this specific scenario. :) No, vmap_pfn is entirely for memory not backed by pages or folios, i.e. PCIe BARs and similar memory. This must not be mixed with proper folio backed memory. So you'll need a vmap for folios to support this use case. > >> historically backed by pages and now folios. > > So by HVO, it also not backed by pages, only contains folio head, each tail pfn's page struct go away. And a fully folios based vmap solves that problem.