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 BC14FC48BC4 for ; Sun, 18 Feb 2024 02:06:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20C6B8D0002; Sat, 17 Feb 2024 21:06:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BB308D0001; Sat, 17 Feb 2024 21:06:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05CE98D0002; Sat, 17 Feb 2024 21:06:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E2A4D8D0001 for ; Sat, 17 Feb 2024 21:06:30 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8A18A8038D for ; Sun, 18 Feb 2024 02:06:30 +0000 (UTC) X-FDA: 81803285340.20.02778E2 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf08.hostedemail.com (Postfix) with ESMTP id C14C4160006 for ; Sun, 18 Feb 2024 02:06:28 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QJQojwRO; spf=pass (imf08.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708221988; a=rsa-sha256; cv=none; b=RhuDKJgSDxV+Yydd6rccl0SWraDoRO9jG5kd8Pc/MQNPOt2ZJRlROA2wfZjXCwhmfhQUE9 FM88YAB5M4EK4aFoSZauLu8bGam2/sb9wroI8XKoaNVHDUCpezpuoqpTR9fQ0p3q9ZVaKf i9Kwrf+muDZJq6Qu5MgVpolMD/5XDgg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QJQojwRO; spf=pass (imf08.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=alexei.starovoitov@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=1708221988; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LspqbKL7rNz4iyMpDNG6Id9vnYOGttAUTDKHLylKfyM=; b=GgekTI4K3e3xJDB+1MyAgXtPvAau7qe7O6wY864ILD1TI7wQWMpjLMr5WIhfhL0toA6NNn ziL0Q1I9fWY9DIzvZGhjFBlyMvhx2HU/UK1x2aAox+TLCz5CdJ/B/4BIleXJE+KglJwhQ8 Fm3g9RVpn0MgvsNj1GB3fqhWqISqPS0= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4125cf71eecso4677955e9.1 for ; Sat, 17 Feb 2024 18:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708221987; x=1708826787; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LspqbKL7rNz4iyMpDNG6Id9vnYOGttAUTDKHLylKfyM=; b=QJQojwROXH/5BVwIHJCABs10tbfZzqjNbqhICaikZT4wBDEfpaOsvb5Fp6bfTiYXiu o8xKfofy81u5xm90tvlbM8lQD936WlNM/kG5F8AnOT9lvDBVGG8I4J1BCorT3s0C7QtK BhrZJ/S8CD9GSJeKhoyVA+r1V+lFANuXA4kf1eHQFweE6GX4aJLdbZJaQRCGo/74E787 U/PdogPnA7+jSACZUxIciBsHQvjGYRuvUpQJj/CFiFXDg89hNEeCKvNn1+ON0x33u510 Gu2SmN0HHhdNfMD4DSc2Peva99EhiaPHJ7rPgbxDgERZ+/zSfx/QuixycRjAJx2mem3f tAVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708221987; x=1708826787; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LspqbKL7rNz4iyMpDNG6Id9vnYOGttAUTDKHLylKfyM=; b=r2F6XvPcNnCQmE3GDWycJcUhEFlsBEChMSoKkUBVaRdyxQoTWc6kgrn0q9D3SXQ3QA sC6AqnbfYJmNUGXWPYCgYWzJeSNhw/ajeH0WiBaVci3h9JvXTus0aoG85sSFR8DbTGbm NVgcZPE8+4IsySLC4I5qObQLjIVE5CG1TwC29LYLx/p9N9tDL5gzJC/w5apk0LeJ/qa2 f5O6vfGv/Gh806amrX8C/21nfFtn/KT7IocT8MUSZ0UJGHej1FWmUrkjfr+s8YvQJNwE 0/6xdls+iY1v6alm39r/b7kMuOha9+gvpkZBkUPCoD4RTobEJVeQ1t+YGVBT8JEMiZGq Dl4Q== X-Forwarded-Encrypted: i=1; AJvYcCW4gdjLvNGxHgd/hIFriwu6EhDI9FcL11H3L6gK2IBMTm7oLZpfJOjYdv8bcUPa+1k0F/ixOz24+4yMRo0bSE6GADI= X-Gm-Message-State: AOJu0YzMZvtvQCn/01fY3CBAtnNC94UXUniDEDyWBnaPKSlA6igIJ82D TaLNg6mKv0HlOt1dZNF+dq5kwUWSxycvwJoL/FZaqHg5GLQr/0BbIqzeWdY8PDJEbRrXrkcTbH5 mkH96SC1X+MGccBqI+ZW+6T+2hxg= X-Google-Smtp-Source: AGHT+IF2lGt0lJf+WbTVS/XPc6/xOZw7ZUacoVQDVPx7K8ic1lgKflcPDrQY5Of7C9uiS+cOXF1PY24v4Kc5nIMBU5A= X-Received: by 2002:adf:e6c3:0:b0:33b:8257:c66f with SMTP id y3-20020adfe6c3000000b0033b8257c66fmr6230404wrm.5.1708221986973; Sat, 17 Feb 2024 18:06:26 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-5-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Sat, 17 Feb 2024 18:06:14 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 04/20] mm: Expose vmap_pages_range() to the rest of the kernel. To: Uladzislau Rezki Cc: Christoph Hellwig , Linus Torvalds , bpf , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C14C4160006 X-Stat-Signature: 3ymxr1cyk6m1owackjyfkcxcsb6tebu4 X-Rspam-User: X-HE-Tag: 1708221988-338302 X-HE-Meta: U2FsdGVkX1/NIpwPl0RXwcyqHckIxKh8q1P2Nt53IeMGIfvEGOVvFwYv2UAAEWEnUn4JzMVwibfOIz8srQqyKjUUH2p4QRIEtuarpPXeO4j3Xi4NgL/CHeOgYFzyDf5f6faCVePjVUW3R9Xy6DnvduEIzIusaKzmPCXaMKW+D5oAc8lcXAYdQwmgq9tnyEp1QCZG7dncgXnmr6eigGcUWs0RfZq8o5+XEA6nOn3uIw1sfL3X8ofOH3wpLWq1k9CWAb6/eJrHJjADLmqAVeaUmdeEwESP/SpBzNCRTm1t/UgIf8/i9Gr8sCyyoZmyFEmV6nRWkEtmqyKzRlieCBnCMGTguQCr1moh5MOTXWxKk2BCb2A+fuxgN6LGK5I0TAdjEAQ+t4Pzbrif6pZTYhW3NUOklvkjkGnRru2QH8TieInGCwQizNzGQ3aXcqsY1HMJIttmoL1/aQDIjmkJVPxGG7395vZFX1OgKg+0Paaf/FCRmh7ksnUgzlmSvLhjsBzUv6UopSD3p0MRxPYiAZDEJ/jZjBFA8N1yB08aYntMwwnnOqCW73P45ibMxpetudTi7JvO6HppN4pPj5RP+OotcxTQlAmCfsevxOq7DMTuC1h56EOR+C4uAmg5f97lWh8PpjvPifRthfJHhl4X0M6zgYkbtC+qpiIagH2dDWtqDgG+lb6p3GdJiVTiBSQq2pombjb6plvIyw1PfCwXU6UYRvX0LuyYPAKtOxyii/N0h8WVtzH3asM74KSFLWtMVfBwOaJPPZLV974R6x/+bsLiuaMW0DskFGpEhuiKH50Rp7Y7d+xWg7sNLEp4ZEVkuwknI8l9m3Bk5TvHqT1oHV1+KSOayHOCyEt7GEvK8QZDpBuDx9yYlmJyanrQnpelJrWPrg4fRCzCDexJtFFWvopdL28DpjNTggt8rpukCR1IOpbhhjVZzV07VX6EeTWEJ5rIEvBsyq0uCf1N2EZFdPn yZgtZPnj DPMUpT3T+G9xCakbpd5DIOqi9fcvWn0PZmPWBkyM1XKxf8Qa2sZtnP5Xlx0EBuUBVRYF7akJAOrE2dpJYL/W1rmRavFA1EU9uLblycWRV1LdtbpIERu3g43Pu7H7lyuAbSyG/6HReSOfxyFgRCaiR87DKzT2yAJncoeq6kcJU/qdNinwkLUbBitv+3OlTBRN5NYmQbl8dQlNdmm8DC4Bmq3swOr/sIJHDUwOjXXZ6TmQul9n7hQ/uPxw5kztpBz2xFURchOIJA1LileWP1npQMQ9UehenCUIGMUjfjpBt7RufT9O0wHsvPHQdSZjsU2yZ2uuI17VhQsBtxaFAJkIMJUwWJV/6s3ZpZduyJMBnfb+Jl8W+T4vpOV+xhItPx0LUhsNEysEp5KNy0WNH5DuS3qxi7vwpgRSLV9hAOv5q5kNHMI0/QStbC1dKSyb7ii46WFMFF7nJWCTHfnsDZhcpikIbWdzOLNI+UsWe0WCdBe6TLQS1w6RbKHM+Hk1iXe8+nVzIP1PftXDZs2I= 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: On Fri, Feb 16, 2024 at 9:18=E2=80=AFAM Uladzislau Rezki = wrote: > > On Fri, Feb 16, 2024 at 08:54:08AM -0800, Alexei Starovoitov wrote: > > On Fri, Feb 16, 2024 at 1:31=E2=80=AFAM Christoph Hellwig wrote: > > > > > > On Thu, Feb 15, 2024 at 12:50:55PM -0800, Alexei Starovoitov wrote: > > > > So, since apply_to_page_range() is available to the kernel > > > > (xen, gpu, kasan, etc) then I see no reason why > > > > vmap_pages_range() shouldn't be available as well, since: > > > > > > In case it wasn't clear before: apply_to_page_range is a bad API to > > > be exported. We've been working on removing it but it stalled. > > > Exposing something that allows a module to change arbitrary page tabl= e > > > bits is not a good idea. > > > > I never said that that module should do that. > > > > > Please take a step back and think of how to expose a vmalloc like > > > allocation that grows only when used as a proper abstraction. I coul= d > > > actually think of various other uses for it. > > > > "vmalloc like allocation that grows" is not what I'm after. > > I need 4G+guard region at the start. > > Please read my earlier email and reply to my questions and api proposal= s. > > Replying to half of the sentence, and out of context, is not a > > productive discussion. > > > 1. The concern here is that this interface, which you would like to add, > exposes the "addr", "end" to upper layer, so fake values can easily be > passed to vmap internals. > > 2. Other users can start using this API/function which is hidden now > and is not supposed to be used outside of vmap code. Because it is a > static helper. I suspect you're replying to the original patch that just makes vmap_pages_range() external. It was discarded already. The request for feedback is for vm_area_map_pages proposal upthread: +int vm_area_map_pages(struct vm_struct *area, unsigned long addr, unsigned int count, + struct page **pages) There is no "end" and "addr" is range checked. > 3. It opens new dependencies which we would like to avoid. As a second > step someone wants to dump "such region(4G+guard region)" over vmallocifo > to see what is mapped what requires a certain tracking. What do you mean by "dump over /proc/vmallocinfo" ? Privileged user space can see the start/end of every region. And if some regions have all pages mapped and others don't, so? vmallocinfo is racy. By the time user space sees the range it can be unmapped already.