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 110F9C4828F for ; Fri, 9 Feb 2024 06:39:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BF826B0071; Fri, 9 Feb 2024 01:39:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36F036B0072; Fri, 9 Feb 2024 01:39:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2361B6B0074; Fri, 9 Feb 2024 01:39:07 -0500 (EST) 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 1359D6B0071 for ; Fri, 9 Feb 2024 01:39:07 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5C53BC01C6 for ; Fri, 9 Feb 2024 06:39:06 +0000 (UTC) X-FDA: 81771313092.21.8C6C9A9 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by imf30.hostedemail.com (Postfix) with ESMTP id 71F4E80017 for ; Fri, 9 Feb 2024 06:39:04 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V61Grgn5; spf=pass (imf30.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707460744; a=rsa-sha256; cv=none; b=Tj1zqtW6eHMhcL79/RjpMwOO59hCBxIuRdnXgl9IYfCmjQ23qCJTq6Mh8/90lNBf4lcUjR JXQKJc5uzro3pxJp2io/gUNP5oFOUIU7kgiHDzBiJt7Rg35sYV4w3sgrWwezT57XyteWzP rP75edsqlxQ4WI1ovU5K4gaxi+/Ckm8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V61Grgn5; spf=pass (imf30.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=lstoakes@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=1707460744; 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:dkim-signature; bh=gGbGyGc8JL/lSzURGkvPdcfI/7YMtQSBWkf15oXUQ0I=; b=4AWbyyt8/Ai0xFIJ8IO4fdae0hFk09KJfwrtR8SOiVTCWZH//uskFnos5WKDnhPpeedVNJ d3kowzj0bbYjEFmK7G3UCoQ478nQRQUlFBX5hMfW4YkX60pwzXd/NEN9hIV1P4ZKomEU/K OkAbI8s7405XyVk0lB84qdt3Az9Qmgo= Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-41059577f26so5726145e9.0 for ; Thu, 08 Feb 2024 22:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707460743; x=1708065543; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gGbGyGc8JL/lSzURGkvPdcfI/7YMtQSBWkf15oXUQ0I=; b=V61Grgn5+dyTu/cPqADPmi9mPGEiSlvvVWxEPlg355M+2rL2zeFCm9UK38PRarZvbb oB71ER0BM85JjydSDGu7IfbHyThGTploumeguIvp/K6+HAWyByv1SYRvi90/U+m4sPrZ pZdX5lh9iZ8wn2WvNfcb2no4axypoLaaMzQIu7bq49ezwfZ2dBh0iQvCWr8A+INrZ5cS qTssirqnVLV6WtXbCxahdVtC++Rm30UWYSOqrVDgNZ3ggiPgHv06cGkbAycws/RQqdql m7NSajkoIhLeqAbaR8ZXb5bWBTv57xRWNwcW688QOpbZt0ZSbNEgjvkPdDUP3kWoEQJG 1ouw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707460743; x=1708065543; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gGbGyGc8JL/lSzURGkvPdcfI/7YMtQSBWkf15oXUQ0I=; b=XBFH2ofM5ZenZCUlnySinDtycZSPOmOLut/I9nZHFOds5JW9ADsgKIyySMqSLDw3OC DyRfA+9rn110HKO3DJJu4QSJ6QF2KiFw4dsdMBkk4l5dtln8BzAzVkZHfzrNzDADlU4q Av57W4auCwYQqFxXPM2ZPWhxC0YK1KNd6p+mJDFtR4sOSKFT09GfovuoeNjqiGcsO2tq 0KC1yCr0UJRhTzwZkDWRuBj6+03Q6xkrkjIZK1RosP95RsZhKEpPvHCHraG5SKdSfDTH DB5UHicTGEZoc5Wba9Az0sVGraUlFxYQutbMF/n9RWcuvt9/EOjrJeV5LfiAc/xGliZy B0IA== X-Gm-Message-State: AOJu0Yx8eLjSZWpdafd2vHzcrWgLoneBRcaFmA0A/SBYlpI+ILjNr9rh Qm28taWOxyC1VvR73B0Pmptbu3FZn1DlkwuOw2cuyHMpM12UeTyO X-Google-Smtp-Source: AGHT+IHH02HUeNDa5Mlgg4UD2e0pVLRle/mWIx2WZRQr8nbdARSwIX/yjti8IJ/t6bPc0/1HIETD1w== X-Received: by 2002:a05:600c:4f43:b0:410:2223:553f with SMTP id m3-20020a05600c4f4300b004102223553fmr419588wmq.9.1707460742529; Thu, 08 Feb 2024 22:39:02 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCX6bfGDSuARvjOJTg7t5TaVK9hXO61Z12WojUwpMtDHtLOG/LZzIfDy/47TcDhZ9fi9Lb0kEzefCRPBucMoceegkMdsmkokMoQ46rT3sVeRIC52mNi9zBH+cGvDVccvSZNTKIY8mkrbtM1fi6w+qrpkV87h8nOsBJIa31w9tEYHtFgOnuEz+iZv2q8YpXgyhtb4Z/a2Hx1HkgzZ3HSxsGRa/dRUYQ9Awwp9YrrYWKBir+l8SrshacqSSlJo/GQ3tPAflbbIgqldjTfEYFJstU2h8tffc18L1RGjpUvYXZ/zghLM/8FbqNHYgxoVpKzDyvbdA0a0S6OEwdfnRbQD6cJ7QQAwSPoHEB4/he10sfmdjLfW5x0Hw7W7BdA1pSIHDPy2NzkhVNNZmwhkccpG+hLJ Received: from localhost (host109-150-53-182.range109-150.btcentralplus.com. [109.150.53.182]) by smtp.gmail.com with ESMTPSA id l8-20020a05600c4f0800b0040fb44a9288sm1538120wmq.48.2024.02.08.22.39.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 22:39:01 -0800 (PST) Date: Fri, 9 Feb 2024 06:36:46 +0000 From: Lorenzo Stoakes To: Johannes Weiner Cc: Alexei Starovoitov , bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@kernel.org, memxor@gmail.com, eddyz87@gmail.com, tj@kernel.org, brho@google.com, linux-mm@kvack.org, kernel-team@fb.com, Andrew Morton , Uladzislau Rezki , Christoph Hellwig Subject: Re: [PATCH bpf-next 03/16] mm: Expose vmap_pages_range() to the rest of the kernel. Message-ID: <16158935-80fb-41d5-ba9b-4d5b9c4d22d7@lucifer.local> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240208054435.GD185687@cmpxchg.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 71F4E80017 X-Stat-Signature: jykhpxo3uzd8bxwhxjqj5p5gbpusjpbb X-Rspam-User: X-HE-Tag: 1707460744-366330 X-HE-Meta: U2FsdGVkX1/LqooKij0+BVgknFF/uME7F69qwJUcm19GApri9BGw8OGL2G8/5104GxWHbYZmOddhgn+9yY1OP3CarbqrOMDZu2zWgLEZd/1ndcNOMokLTCGwTWilviZQbOrtIduumckFS2UEgfFQNbQkbdBLs2Xn17HWDh2a9nhPfpeDY8dpkipUyH2t8vkuoz9uwOWdJvby3/MXrl6amY8JA4+goK0eG7c8B1kG2iJvc6YTVCQc3NuUhF3XS4DGAUMrsd7M8c+lq5U0NclZFSBeFh9f2uvf5YLdyj5coC+DVVudHIgLJhMHI/3gqjADxdVW6MDzsrZt5CTeSPsq3LynkqCHhnQ2Kd88Z9pnEG3NnoPR5TU6yxcrlB30Yeb8obRPDPE8p8hWPIOhmOKgFvCUlP90RTnkz2C/wRxr/kf9G2CkB+jU+LWMdTeNHzS7ORmnVHDjbHMQ1mX+oIxnDE1ERTNU6ReibwQ1IEl7Zfc0G08og/ZFRUQFrcLPXPsaRz/UuE2BcRarm/30CZ2OXQrM7Eh7OhVBqw5lFYdbZRzgxycwhXSq9Ru+wn+BYlZJjHchvjF3UR08bqMsRJWuaZ1SSsvR0YszSuLN5ZY2q8wnDZfurDPbbBkq1gMnkFU8aoGaQWM0E8Sav5jnX+4PTj8IfpmulK9g7NmHfJhXIArzImIA1Y75AzZKh+XH87XjJEpwJd2cddu4RyDRkR6JPK5Hm8reUKYxoQDis8bJQVdhljOWVvMWdLUTz8dvvDxAh5IsvyK5vVojgvJbXsRHimenaB4XSivFX6rubcuoEXY9fxDzfzOmkjgNavDTajVNDKzbHzpwDzKnGLdNbfx3cNB0buvcFz0h2UAo0nVgVZW4a4e2fQw6qVJcM9QBFj5qLMeK5USouzpMf4JcQNhM15ejY6ZWSsFEmIhFxSvzJnX+6LOFV0AMXW7fJ2swcjwcAug1DK02812xMoM4ohU 9BHS19jh ub7aH6kjVupRGIU92jMcyGjXHKcqAUZDumtFQNL+htD+vxgM1kAG4LoLrQISTnMqcqBxZH3CZp3BubMW8RxHTUbuor/FMPVYSHm86rXcFN+FrrV5dHNu7jIhI6RnqeltlrBoHEx0aZU4ig0bzvWrtzFwYbfoFKs3rQK+pedGO9NmazpQ4MzDg0pO/IdoY+CW1Wpj/H6fTw8WBaAb6+7LlAt6hcxA8ytwTsru1ftYgiR34nrFzQg9lZJtV2zkKCrFpw9jmidOTDySzGR27mKRcjtG8fpQ4hB1PN10qumAXHEE0bapYQPLi7HNShRBMYHZMue4xrZV+CFeP9HDVw4FJx2QugWissyGPlmrpX8EWIWt8uuGTfvwUBZ+1XiqMMuUnwxxlOhD7BJcQVmoAbn8fa9fHclBqwLL8cTULZe9NLBMLI3gUoXZi03JBekYBaaeBqnSJrDc5mzHxuWTksSA6543X7GJ7lrj6049pKB2CdNKP9JlBhIKhj6TsQwmWEV96tgARjeGWNbucsyctFRyoPPMXGVuM4qFweyyKUitqM1QCWoK4CelD6BlqWePJedvhDIdaGPRHC7d1LIU084nCL0lL9nBu+VceNvbfMBYaznv1KTc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000095, 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 Thu, Feb 08, 2024 at 06:44:35AM +0100, 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 populated 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 this > > internal interface. You need to put more explanation here along the lines > > of 'we had no other means of achieving what we needed from vmalloc because > > X, Y, Z and are absolutely convinced it poses no risk of breaking anything'. > > 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. Thanks yes this is much better! > > --- > > > 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 other > > 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. OK that makes more sense re: comparison to ioremap_page_range(). My concern arises from a couple things - firstly to avoid the exposure of an interface that might be misinterpreted as acting as if it were a standard vmap() when it instead skips a lot of checks (e.g. count > totalram_pages()). Secondly my concern is that this side-steps metadata tracking the use of the vmap range doesn't it? So there is nothing something coming along and remapping some other vmalloc memory into that range later right? It feels like exposing page table code that sits outside of the whole vmalloc mechanism for other users. On the other hand... since we already expose ioremap_page_range() and that has the exact same issue I guess it's moot anyway?