Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
From:   Michael Kelley <mhklinux@outlook.com>
To:     Christoph Hellwig <hch@infradead.org>
CC:     "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
        "kys@microsoft.com" <kys@microsoft.com>,
        "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
        "wei.liu@kernel.org" <wei.liu@kernel.org>,
        "decui@microsoft.com" <decui@microsoft.com>,
        "luto@kernel.org" <luto@kernel.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "urezki@gmail.com" <urezki@gmail.com>,
        "lstoakes@gmail.com" <lstoakes@gmail.com>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "ardb@kernel.org" <ardb@kernel.org>,
        "jroedel@suse.de" <jroedel@suse.de>,
        "seanjc@google.com" <seanjc@google.com>,
        "rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>,
        "sathyanarayanan.kuppuswamy@linux.intel.com" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH v2 3/8] x86/mm: Remove "static" from vmap_pages_range()
Thread-Topic: [PATCH v2 3/8] x86/mm: Remove "static" from vmap_pages_range()
Thread-Index: AQHaHMCcNHra+kumRUKExlyvEEqwbLCF4AyAgAEpOhCAAHuSgIAF2cCA
Date:   Mon, 27 Nov 2023 01:06:06 +0000
Message-ID: <SN6PR02MB4157CF2A7C5064889843D79CD4BDA@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20231121212016.1154303-1-mhklinux@outlook.com>
 <20231121212016.1154303-4-mhklinux@outlook.com>
 <ZV2e/6qTJDkjYbfY@infradead.org>
 <SN6PR02MB41571479B921621EDE3BE2EFD4B9A@SN6PR02MB4157.namprd02.prod.outlook.com>
 <ZV7//Yjx6ngKSf0M@infradead.org>
In-Reply-To: <ZV7//Yjx6ngKSf0M@infradead.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QNm+2Y/9H9BB7qvg69Bb9JgxlHERT+21UEB0/HpEFAXEo0hkBMglPFWxaF02?=
 =?us-ascii?Q?UvXvy1gXsspLeE7Xx9k4DSv6T616ezIh+ynd831TTZLP57MGdAAR+ThXdF3f?=
 =?us-ascii?Q?9pML6cwrjbXn1+bhINM8Vf/87elx1aieCm/99bAwRiAN964h4Coep2t/qxpa?=
 =?us-ascii?Q?H6Z61MZ4t9xITThEVWYyyH4Xn8nBG5DMEkhjhn3dJlvMFIK8cyLPWpKDx7jp?=
 =?us-ascii?Q?FV41DSbkupMfJDHd/18I0jdijD2/SL4OefrIcRHUtn3Tij+sWT+1tcBtQcw3?=
 =?us-ascii?Q?v2p7jlS/jk1hEdA/2tuINH/tYRCTF6z0NA07/bcnKDgQrHpKjh/Xf6p0AxLG?=
 =?us-ascii?Q?olluCCnfqLHg1l1OyopHNItcLtsL5GGXLZcGLI7EYqlWmnmeA/CFO4LbADBb?=
 =?us-ascii?Q?neKYuDYlrn/z/sHmZCvPILk0elP8I9kESegKwT/13XS3QaCJaLFINJSlUt4j?=
 =?us-ascii?Q?RFR5WXys6Mxd/PyJ6vf5RWqyXxKybEPMMgB6wVcKJMAemB+Nef+4Zmusd2eb?=
 =?us-ascii?Q?GKQGkBHuxWp51pXshzXOjPI34a5RAEqO6ZTDDNeNCiwfRAt+akATzloks98x?=
 =?us-ascii?Q?Cn66onciJwI2MTKnZ2KWz/5BDy6YCANQm7RckIDYgzZnq0QBtXamnar3y3ny?=
 =?us-ascii?Q?AvEVHTq0UoDMaaDY8IcjySsojwTe+vcaYcFR2uS6RgGZA1HI4S1FsSsvbBhj?=
 =?us-ascii?Q?XFb5CbXxJygUBjP0D4fD+nja4A0YL/4fbWSVSFE+FPKC1eWBE/KTab8elza5?=
 =?us-ascii?Q?GUXBUyGfzt5bugQNSap8LpetHPvbeX7bLGkYvl6qfzt5IiNN8BS59qiWhQ7p?=
 =?us-ascii?Q?/z96y1zwxZd/G6Y+FrEummobaO6/Tjw0hka9GWo1oa+PSb5yIVCDLz/AQFsj?=
 =?us-ascii?Q?Eg6jeb8mbiBT73rc2jrBSGQ+eOEVwzR6AGUzfofmInM5mKvlKW81Spf7wcIb?=
 =?us-ascii?Q?Ymc5FUuacM2P2/BIgKHCaOJE4Udew1tFDvysXjZ8Y7enEED+ZzjhYgt6ejm4?=
 =?us-ascii?Q?3ClWJtCi29F5PeZs2o+5PF05pOGZyNDhwOIgBOd0bmP+jQNxul8O3JYRc5sA?=
 =?us-ascii?Q?OqoLOSg8QrFpyeVnjZECoBVNcEAghPuOBG7QKTI+r8l7chThz5xhp2MVMJ7g?=
 =?us-ascii?Q?/NbT196UaWh9r6SHmdlxkY50J3RsZQ0YUNcjtCOdr16vV93/ZudJewsjr8Yc?=
 =?us-ascii?Q?bmkRKH9EkQLE0er71pDjY1RiCa0lYY+7822PSA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f9e86026-9ebc-435f-1284-08dbeee508ad
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2023 01:06:06.3058
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6859
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,
        RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Sun, 26 Nov 2023 17:06:17 -0800 (PST)

From: Christoph Hellwig <hch@infradead.org> Sent: Wednesday, November 22, 2=
023 11:32 PM
>=20
> On Thu, Nov 23, 2023 at 12:24:49AM +0000, Michael Kelley wrote:
> > > I really do not want to expose vmap_pages_range.  Please try to come =
up
> > > with a good way to encapsulate your map at a certain address primitiv=
e
> > > and implement it in vmalloc.c.
> >
> > To clarify, is your concern narrowly about vmap_pages_range()
> > specifically?
>=20
> The prime concern is that it took a lot of effort to make
> vmap_pages_range static and remove all the abuses.  I absolutely
> object to undoing that.

OK, so I assume that means a new variant of vmap_pages_range(),
such as one that always sets the page_shift parameter to PAGE_SIZE,
is also disallowed because of the same potential for abuse.

So the only way to map a system memory page to a vmalloc
vaddr is via vmap() or some vmap() variant, which always
creates a new vmalloc area via get_vm_area().  I've done the
perf measurements, and that approach won't work for this use
case.  Independent of the alignment requirements, the churn in
creating and removing a lot of vmalloc areas has too much perf
impact.   The use case needs to create a single vmalloc area, and
then repeatedly map/unmap a page in that existing area.

I'll have to handle the top-level problem in this patch set in
a completely different way.

Michael