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 C13D8C4828F for ; Thu, 8 Feb 2024 23:55:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AB4E6B0080; Thu, 8 Feb 2024 18:55:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 334286B0085; Thu, 8 Feb 2024 18:55:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AE1A6B0088; Thu, 8 Feb 2024 18:55:46 -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 057C96B0080 for ; Thu, 8 Feb 2024 18:55:46 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 958CB1401BD for ; Thu, 8 Feb 2024 23:55:45 +0000 (UTC) X-FDA: 81770296650.14.BBA5939 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf18.hostedemail.com (Postfix) with ESMTP id BCB521C0017 for ; Thu, 8 Feb 2024 23:55:43 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=H9h6EKQa; spf=pass (imf18.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.50 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=1707436543; 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=cOwD9fsxjkKCfa1uqxYbAiELsTdDI2nsWm37wiJ3YbE=; b=1EzbZVYJnF1u3UE23JStTewmdFiWAipIlUfKAXxI4RwZOHC9aKclkbQHbwojbKFIP56UN4 pcFbyaGxa0DQdk0vXU9G1XxSRIKAphGs/sHvOge4YvjHNLkSb1I/++XyS/n++QmxR6LuRK tHuJsQtysjzEST14esBq78aqY9oBQlk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707436543; a=rsa-sha256; cv=none; b=6RjV3BwGjnq8cVYfGXQ5GWA3jl7fgHAIjSVLhSQYL+iohWr8/Z7u4igoDnjgquJW73BXgq Lr6OL/xDyGuG+RHCCbMzJDtcERD4PBBcGjZ+9PT3pI9OThcEDVqYiRQpWYz+VXPsKTrcON LuuBBR6+ik6hyww7bXuZdQEU74ATbdE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=H9h6EKQa; spf=pass (imf18.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-337cc8e72f5so172790f8f.1 for ; Thu, 08 Feb 2024 15:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707436542; x=1708041342; 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=cOwD9fsxjkKCfa1uqxYbAiELsTdDI2nsWm37wiJ3YbE=; b=H9h6EKQaMEpLhL13ADJLFtJ1DKirntIgNcT2P20POwozYvoBynmp0xqwWUePMT0jEP JlfBFPsL5L6bcqRc9OY5GFQrT0P72jRtvCV33uCT7qW31bH39BoKbo9JF7xPF6vgW9pP qcd1m8AZbf7/thwondgOgAfK5dE5yeNduNhj4jWDQpMPjx/t2uYSznKHlY13Lahs6Dyp 7gSMaBRprDxQT+TNz2PSV1G2Zs5TQ3jpFV7LRLO1uliCzDovl0jG2lKuOkWRnuw7JCwW NLL90YLkWdntPttzVEOugSBtcdylqsT5xnTdS8TNkxIohkELwpBSJx8f8HgkhFvYN2RG 29EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707436542; x=1708041342; 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=cOwD9fsxjkKCfa1uqxYbAiELsTdDI2nsWm37wiJ3YbE=; b=Vfx/zfXyiaAZ5ISljLcQXw8DWFbyOfs2z3J0a52Xx8GxI85Z+1k98NbNWvmNfVZERm JMP74zzd8M15hpX7k5fbXIjjehtfGrE4LXXJD7xc+YnCvQN9V4WVjogJjhkYB5cdSUPa wC9Tuj+BKnuonN6qCbt0M+eWD8IdaM/KfdisAqCURRrKos27olq0xEIFPDHxFPimsV4W r4kkZZY2iyzQZ13Nsf/7Ia/NkONlHzMvLChMzb9u+GbzS/A/gUbpZ9cjRgb3IJ8vBUl3 Xa9KJZxl2kejbunDtwGAvD74SAzFaZ4rDjz3fTg/kVUb+sELziAZjhzxWkS0YraaY9o6 JIVQ== X-Forwarded-Encrypted: i=1; AJvYcCU3pewg1g3LUFMzU51BJcuYQHAfDp7gBtoESChbEugmkroFKDp4876pT68zBedwNJHB6pslFgrkADrn2GevvtCmA5w= X-Gm-Message-State: AOJu0YzlkhcAf+JdIshPQdXjfbUbfuo0eWfecfToxSe6ibICOLZCDnVg mQdvreVqupO0+JXWn74QvgxcTbcF7x7W81EMBRtniWUf58pIIrOla1oH3igrMeR/6EYJ4RzmmIt 5Gcc3TJ8n8gGi723RSKpXGCnchBc= X-Google-Smtp-Source: AGHT+IH2ozbJe/5f/985gljgNrdsyqP2YJhO0Zsg4x1ggNQll0eahn1s6qo42LHHos5gUtcpiRJJdjC4iTZP+mOX4NQ= X-Received: by 2002:a5d:4a8d:0:b0:33b:2332:75af with SMTP id o13-20020a5d4a8d000000b0033b233275afmr611606wrq.36.1707436542072; Thu, 08 Feb 2024 15:55:42 -0800 (PST) MIME-Version: 1.0 References: <20240206220441.38311-1-alexei.starovoitov@gmail.com> <20240206220441.38311-4-alexei.starovoitov@gmail.com> <30a722f3-dbf5-4fa3-9079-6574aae4b81d@lucifer.local> <20240208054435.GD185687@cmpxchg.org> In-Reply-To: <20240208054435.GD185687@cmpxchg.org> From: Alexei Starovoitov Date: Thu, 8 Feb 2024 15:55:30 -0800 Message-ID: Subject: Re: [PATCH bpf-next 03/16] mm: Expose vmap_pages_range() to the rest of the kernel. To: Johannes Weiner Cc: Lorenzo Stoakes , bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Barret Rhoden , linux-mm , Kernel Team , Andrew Morton , Uladzislau Rezki , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nk3tcuurqgdbb9op17c6dkuazp1behoi X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BCB521C0017 X-Rspam-User: X-HE-Tag: 1707436543-864270 X-HE-Meta: U2FsdGVkX1+MLgzfDx3I2ia6x1tfmiykBf/q4amQhp6TjKVcnz3nsgwDLp1dWmw3axN3eeqlm0nFa7VITSdH7eHzYNEK+uB51jifqL0gWTaOraFtvVCmnG+oq4SVU4JCEWki81x15aRtb+Lw9UbRb/nfd2RkVtFS3XvbAEpBEfzgugZKUdbOBB3PBJHOpxmBZayjbrdg8AWjI+5s894QKtOiQmdynqY8v6bxsxfUwzHj5apfQfuu4thXOlWLML6LxnNQaWXKe7Xz4wn5cm7g7CQ6MdIeWfLDYv6TLzgdyB2n2eqcXeRPExCoHF8TXnyszN9ZZX9tcFnDmq75Rd5r4XzdkVSSRpzuj8vlIaTmBe7qnc0T1Hbz5TXfSj+RT6od8djkvuLMV9CZ6sxgNiN9wvEkAP+SoEZJ7Mpm6jHeKFrmt6955F7dcImuguqjW44+UskrIRlFsADgaTXNtc9LV5l+D2goBnh1hWoR5DHgxOK/N9fngsdqgBn7mtGXITuINPIYmdGQRg1la1T1skjnNfPxO1JyUbzkCFBMiABeAMMk4YcQVyTzlHyfXwEE0o7gbOQ+PfHr8tQMFFxKul71OjyXYxDArWBS8zW2RRt78Vsf1Mf49dI19NEG+cLk1jVDb7a1wGFBPtcqjVWKlkXYQ6M97zR6N2grDIseuprImwi142qeDMg9MDzraKgP+BhIlcNYbJwwmeywSdzVqgfOE3886kYJOGLXRcUF/k2rd/CpNXdXHEBi5NCbJ6J+tLQ3ppdOrm0eP54ZnTE67/Yxv30S29aR3cDMmJqyrRq3d6WvlUmUBPV6RCIwH/BTpYUGcNt47/n5udEXij5oOdIPO1oAcXNWnXgsFbuWURp466KaswyVgQ2KNeTja0ftCauxI2U/PwBYTckF5yUFfCzKA0WCST7PR9+gXbv5W2FnGg3BXjjqCFL/InTc/9cX9MF/WhXUOVxa+pcQE5MP7Mq HqhCJifU XIMsOZFxx9Sg5p22JTTf2bjhXSEDs1FaBZzFr56jzk7v1jhfmgHaEYUtKH5FNuHvT4yjQI2vKdk5EvGTt22TWv06e7Y23PkAcBzMkNwV3NwDVM8lIFRoRv5vme42jBzojWzoUp7u3YJNltYqIoeutpmcXzP9tohqhBorsgY7HFg11oRS26BK6jH4vafpZjielUq/f+T9kQ/l2d5qsHkI6oZBPtTNsSB4KiP33hUI80t5niLrVbg/m6W1VrGhAh7vCiqFXv/Vk0cqW35cNutVqP5iJvaDx1ee28UbqUIj9WNFOI2e5Ia07CXhqEgumbpMAtAGsdmJ6yaS2/fWpqf/a1WMZcZ8Xoxiei8ST0novgJsWMH11C3cu0hCKcB0PZjo7yCq8h/7G5YKXpUf6hGD+qUWHH8e8ORLnKcLZ9KaYbFeYlRYtiLuOQCOcN8IjtcExl3l5eo0404I1ezjWiPIKinmSE4fB3GL4W/qysJb1MzkNQVJAz7KaKYvO6pl8eURSTePJ/cAjbD9nrpEtdWz9eEZOXBA2ttRNUC7gITc5N5TMNiM= 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: On Wed, Feb 7, 2024 at 9:44=E2=80=AFPM Johannes Weiner = wrote: > > On Wed, Feb 07, 2024 at 09:07:51PM +0000, Lorenzo Stoakes wrote: > > On Tue, Feb 06, 2024 at 02:04:28PM -0800, Alexei Starovoitov wrote: > > > From: Alexei Starovoitov > > > > > > The next commit will introduce bpf_arena which is a sparsely populate= d shared > > > memory region between bpf program and user space process. > > > It will function similar to vmalloc()/vm_map_ram(): > > > - get_vm_area() > > > - alloc_pages() > > > - vmap_pages_range() > > > > This tells me absolutely nothing about why it is justified to expose th= is > > internal interface. You need to put more explanation here along the lin= es > > of 'we had no other means of achieving what we needed from vmalloc beca= use > > X, Y, Z and are absolutely convinced it poses no risk of breaking anyth= ing'. > > How about this: > > --- > > BPF would like to use the vmap API to implement a lazily-populated > memory space which can be shared by multiple userspace threads. > > The vmap API is generally public and has functions to request and > release areas of kernel address space, as well as functions to map > various types of backing memory into that space. > > For example, there is the public ioremap_page_range(), which is used > to map device memory into addressable kernel space. > > The new BPF code needs the functionality of vmap_pages_range() in > order to incrementally map privately managed arrays of pages into its > vmap area. Indeed this function used to be public, but became private > when usecases other than vmalloc happened to disappear. > > Make it public again for the new external user. Thank you Johannes! You've said it better than I ever could. I'll replace my cryptic commit log with the above in v2. > > --- > > > I mean I see a lot of checks in vmap() that aren't in vmap_pages_range(= ) > > for instance. We good to expose that, not only for you but for any othe= r > > core kernel users? > > Those are applicable only to the higher-level vmap/vmalloc usecases: > controlling the implied call to get_vm_area; managing the area with > vfree(). They're not relevant for mapping privately-managed pages into > an existing vm area. It's the same pattern and layer of abstraction as > ioremap_pages_range(), which doesn't have any of those checks either.