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 D3894C48BC1 for ; Wed, 14 Feb 2024 20:53:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F1E26B00C1; Wed, 14 Feb 2024 15:53:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49FF16B00C2; Wed, 14 Feb 2024 15:53:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31A3B6B00C3; Wed, 14 Feb 2024 15:53:58 -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 1DF116B00C1 for ; Wed, 14 Feb 2024 15:53:58 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E53CF1C18E6 for ; Wed, 14 Feb 2024 20:53:57 +0000 (UTC) X-FDA: 81791611314.11.8E0986A Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf03.hostedemail.com (Postfix) with ESMTP id 181B820016 for ; Wed, 14 Feb 2024 20:53:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fFynSC5j; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.49 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=1707944036; 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=Pe2hn34Lmye40DJleY6hu+u5gVtFILc8D1dIEuP6Oeg=; b=jrQc1yXYRtlLB2Lp+sI1xXLN9thWbzd9WyGQa4QisRRypx/j0p0CggHH7d1m3Ji5QQf6dH L1OpmI46ErW0c7umZs45q4sbPdrcF2AO3EwK/CLq7Qjib5ii9N3fneEYdLOHOeEi5QDToM j/XgeZVmuTQOV3oSU1254DWR9Z/0fRI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707944036; a=rsa-sha256; cv=none; b=CNY/7pjJKNyIN6hG6yfK37jooku3aBoISk0Jv9lTuGHXuMrhsfFCJgxRcXh7UzOnZkRMS4 QuuUzdmViyRpb95X1hXKPB45W+A5XF2rws/HNjswMEVTBymgkLK1x8q3rKC3FcCJJLRK24 djT+iv4Whm2yBFUcBSCLz3rt1ZCGCjE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fFynSC5j; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-33cfba7e7b8so18921f8f.0 for ; Wed, 14 Feb 2024 12:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707944034; x=1708548834; 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=Pe2hn34Lmye40DJleY6hu+u5gVtFILc8D1dIEuP6Oeg=; b=fFynSC5jSaALTiAtV2dHjY8/HgRUa9R1rXfGmNEfUHiU0JCr7dJlFa2CJr8NolH6Ef +N6YgAqPh3zz+LlYqdsl1FdIWHGj7vYNBgXVxSYy754v1ZdVF0Af2wM3ibnrzxPihpNY P5/ReKbpCXlPCRfrXEbKprlGbDY7qd5oNj4BbOQDLZVOISkYcO+7JfiKZ2x9XMQMLkTX ODH7XtVoRiatBwYR6uS1iWf0fTwzYXRhB3mxMq9jF99CgoKMOnj18j7fjxD4zoFJ6Va+ oGOubmMV/8zkLiTtQqSyy7ncMH+YvBp09phzEv6rmT8Y0wdaRQAy5cIi8Z9dVxEhb3ab aU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707944034; x=1708548834; 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=Pe2hn34Lmye40DJleY6hu+u5gVtFILc8D1dIEuP6Oeg=; b=SKQw/x6ybfhVQCnUjeXdJdaCC3qgvifSkfNSQ5ZbcZBS5so4XHIvQqqf9VR9GRzD2B 3gdgh9KNOaZznFfLUVG7WHZ+W1UWRQRXDKW5vfZD+Hz/ronom8AC+3UJNYf/sl/OIoZ7 oY0mJmQvPNTpI8M9y+4BG2eXm+64DpOiU3QQbbe6FKapzkaNRfKKxkZhwpVyaRu2OeN4 2AvJDmK3oNR2NdYlmNtI4+Ugv24Apn/LoudNMpOp0IoWbYQlA+EfWlTVgDgJK/lzBKyn ImhtdbD+qD3xwXtaLSvcd6ft+NeP5n3HHaYyjC2H3gvvNrKEcxk0rncsad6weCnvZJRd T0FQ== X-Forwarded-Encrypted: i=1; AJvYcCVVlOuhXTYxHlwcA6kI6IS3M+4Any97gTRCE4ghELLpqEOUTZEosRvn+BK8D0DdykS6unSTX8GCvnet7PiMld3En80= X-Gm-Message-State: AOJu0YycGSssWTQ1kcAc2fs34ebn4zqe3AzyojLkTQSun5PwYGqy0X// 5ZtR1SRFII2Apyx2BDcWmDhYW+YzKljUqMoCqCoydck6yluPvE1gO9qnAjNoT+PPZfinzSuWy6V /opDzal1Taf3IQmwTTT8nvkwTyG4= X-Google-Smtp-Source: AGHT+IGjrO30IfUr6L1g726G/SOGM5XgYh8KeFxxWlfBhOTn1VUg6r/0IWN2orJ8xTjz3YsZdJM7fl+XzzP3bvJi4CM= X-Received: by 2002:a05:6000:118b:b0:33b:794a:8a79 with SMTP id g11-20020a056000118b00b0033b794a8a79mr2543650wrx.47.1707944034238; Wed, 14 Feb 2024 12:53:54 -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: Wed, 14 Feb 2024 12:53:42 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 04/20] mm: Expose vmap_pages_range() to the rest of the kernel. To: Christoph Hellwig , Linus Torvalds Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 181B820016 X-Rspam-User: X-Stat-Signature: bwhytbb7a3x6chtzmy5ncss5twzeizrk X-Rspamd-Server: rspam03 X-HE-Tag: 1707944035-19824 X-HE-Meta: U2FsdGVkX1/auFtWPok1uLhgEf9JESJdKBsSoKsU/gM3cCovq70NXYTXEl4My7TVkJTmfUn2v7tg2r4iJUoBuDg3I4xRHElOC1qHyf5pU94aslhGOz0P4K8jxLPYxnmKPUVG8E/I3KTNBCO7QrBnnvU1mZdgNWCyTe/Axe/h7xDZmt0tu9xBEp5RW6QF1eM4ofnkQdnezHYHvzleoA/RgatOcomf4ZGffPeqDb8vxy6XNCutfQuKI0WUHlcFv2KQreHrFbkwGNFxCjy15+QK/ZOOwr7gQUuT7Tw+M+MDhg6A6nGZlhSWC065b40ujqWuhf71XjslJe72LdpCtyFupv5xCiX+lsujQibCgQxmeanEI9sF1sDdQLf5VsogWvvLy3wSKRjNDAhWuJ+sNFRexkv24uuU2oowfektRjZyT0BktYf0F8h46QobcPZDJseDkKdML1O7+GGo5ZrBC90dvGpsCk7acR23DzmfBp5g8pci/RqAuRdFnJI7ShrhF+5zwoNQXmazoMGr6KTPQmVUrBGoXutJIkUpGT6MwlF2FNFPinkR650jRivN1huvFefxnKGM27pGyghh6ifp9dIEL7bHgBFBzoh+0sWj3ITJuR+vTeHfOlzpmnHz3pOPG50ERz527D9YECZgUHMz3mZVb1BW2/aR7b7x007xbMSRjTFmUYniiHtkCV6wUN82HpXci9lYi4tvGYY3cfe1hvyKmQHnNYHaM/5/L1BTfaqG/3GVi84Zs8A7yF4RS5QY+R9XRIVyZ6bjNGbgiy/zlCrLi0o0Q69wDoY6fa/Jg9qCet0GgPbgsuWN2SsumkjOvX4zQ+kwswywr7l+S9DBRC8bUs03MmFTspo3sXvXTwaBaeHqtFC/nwPo8aBm77satgfwuIb5Au3lHcuRcpwvIol1IrA/SZkDSZZLxD5OTfAiYMW+Z3WtSlDITaz8Pyz/u+WW2ivNxyqWEJxCKTw7fKr MjEAvWh0 hdAZrjrR6lON6PwWCE2ftELNPnj0VOjh73QhPERCv476rvq+0uXurUVKkdlQ3siLiUezr/iCn8BA50G38taNA6b5u1+4nraXcB98WssyClR19JPxcAHSxehHCzixscJSDK0tjfdAtbOdHgHUjuuP7Nyzki9vKzIkq22jryjnrYcXLU1A+kcUpFvJuxlltGCLhOOJUTyj2jncCXZyCG+EUg/8XSf+AjrpLhMh+DhypUFuDDkOXBgJ6RTgTY4La6Y2gIjFjjLJ4X5X2Y8qY0RLJjEsZM9L2obYeRmuse0QiRmaCc1lCDb0HL+jGoWmDbf09s/aR323tjJQWSXYsqAfuDz9eet3iu75URgxaCZAPX6vpcWQD9pG5RZ8KgzitbEVXk0QWNE999RaesJmTa+OJUN2d5Zr2D0G4flJKOTvoWyNtbGEBLxy+dDbvbceZgO0Op7G8+7VVhAFdH4E/s4GbKcL8hGbo21h8YVhZpCwfvX3CKPpLyIPeKRVP/2BU/GSQzcrvQjVBhM/ZbKFyLs5/5I9XpRMugE6jISGzZDOTpsIukvc= 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 Wed, Feb 14, 2024 at 12:36=E2=80=AFAM Christoph Hellwig wrote: > > NAK. Please What is the alternative? Remember, maintainers cannot tell developers "go away". They must suggest a different path. > On Thu, Feb 08, 2024 at 08:05:52PM -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > 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 > > What is "the vmap API"? I mean an API that manages kernel virtual address space: . get_vm_area - external . free_vm_area - EXPORT_SYMBOL_GPL . vunmap_range - external . vmalloc_to_page - EXPORT_SYMBOL . apply_to_page_range - EXPORT_SYMBOL_GPL and the last one is pretty much equivalent to vmap_pages_range, hence I'm surprised by push back to make vmap_pages_range available to bpf. > > For example, there is the public ioremap_page_range(), which is used > > to map device memory into addressable kernel space. > > It's not really public. It's a helper for the ioremap implementation > which really should not be arch specific to start with and are in > the process of beeing consolidatd into common code. Any link to such consolidation of ioremap ? I couldn't find one. I surely don't want bpf_arena to cause headaches to mm folks. Anyway, ioremap_page_range() was just an example. I could have used vmap() as an equivalent example. vmap is EXPORT_SYMBOL, btw. What bpf_arena needs is pretty much vmap(), but instead of allocating all pages in advance, allocate them and insert on demand. As you saw in the next patch bpf_arena does: get_vm_area(4Gbyte, VM_MAP | VM_USERMAP); and then alloc_page + vmap_pages_range into this region on demand. Nothing fancy. > > 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. > > Yes, for a freaking good reason. The vmap area is not for general abuse > by random callers. We have a few of those left, but we need to get rid > of that and not add more. What do you mean by "vmap area" ? The vmalloc virtual region ? Are you suggesting that bpf_arena should reserve its own virtual region of kernel memory instead of vmalloc region ? That's doable, but I don't quite see the point. Instead of VMALLOC_START/END we can carve a bpf specific region and do __get_vm_area_node() from there, but why? vmalloc region fits the best. bpf_arena's mm manipulations don't interfere with kasan either. Or you meant vm_map_ram() ? Don't care about those. bpf_arena doesn't touch that.