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 1E5F3C433F5 for ; Wed, 13 Apr 2022 00:35:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27A1C6B0072; Tue, 12 Apr 2022 20:35:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2291F6B0073; Tue, 12 Apr 2022 20:35:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CA0B6B0074; Tue, 12 Apr 2022 20:35:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id EF34D6B0072 for ; Tue, 12 Apr 2022 20:35:31 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id B44A161D11 for ; Wed, 13 Apr 2022 00:35:31 +0000 (UTC) X-FDA: 79349987262.11.2728DB0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf20.hostedemail.com (Postfix) with ESMTP id 0DC3E1C0007 for ; Wed, 13 Apr 2022 00:35:30 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 74433B81EF6 for ; Wed, 13 Apr 2022 00:35:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C4D6C385AD for ; Wed, 13 Apr 2022 00:35:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649810128; bh=AmfvMR6B8qWiar02K5X7Z8KIhMvVMGBK0eqEnVrFYpI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TxSzzlCOKE01p9I9UE5gYaWOCURLBMQJmIDI63cp2ILPaM5AZ/T9SPl3gGt7Pe99H SoxXtP59LPHy1mdvTMTOEvEJbeTILyT0GJeTK9C42LX5qkNHjbiXLa7/KzmBGfEJAw zUnY8CksJ6rKwIctIDPek8FU/OIXKLt2XZePPHzZlCIyZW5C9OuNVkZq9QO+9u30IR srLq82ZNl4Ijrnf1nB0oEdZlrb0o6i2CGiCjoUiW3y+BsbNd20R726D/TTXZmpFYeT 6YFqnCAvixY4GGkla4N/uspLDXyzEmItxAyroL0wQkZ171htOphChzjaWOvy/OvwJ9 F6QUnERcd4aBg== Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-2eafabbc80aso5526007b3.11 for ; Tue, 12 Apr 2022 17:35:28 -0700 (PDT) X-Gm-Message-State: AOAM531B+O5s7Dgm/RNzjxbiuYSXiZPkz0+BnLCReKQqkmqqIjCpq6RN 4KX7Q3/MZpdNsDXyb1uS9uExwih1dnpNaFp1MTQ= X-Google-Smtp-Source: ABdhPJxdJyCJBgAjK0m6B/QRCZoAaYow/4ZgPbqC+fgtzHksYWemDjn3nzAKx2oczPg0w5rKoB7gHE62aESus4w1jLQ= X-Received: by 2002:a0d:f6c6:0:b0:2e5:bf17:4dce with SMTP id g189-20020a0df6c6000000b002e5bf174dcemr33657904ywf.130.1649810127216; Tue, 12 Apr 2022 17:35:27 -0700 (PDT) MIME-Version: 1.0 References: <20220411231808.667073-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Tue, 12 Apr 2022 17:35:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 bpf 0/3] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: Luis Chamberlain Cc: bpf , Networking , Linux-MM , open list , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kernel Team , Andrew Morton , "Edgecombe, Rick P" , Christoph Hellwig , imbrenda@linux.ibm.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: m85nft7e47ogsheoui3n5oezaef3otnm Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TxSzzlCO; spf=pass (imf20.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0DC3E1C0007 X-HE-Tag: 1649810130-995366 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: Hi Luis, On Tue, Apr 12, 2022 at 8:38 AM Luis Chamberlain wrote: > > On Mon, Apr 11, 2022 at 04:18:05PM -0700, Song Liu wrote: > > Changes v1 => v2: > > 1. Add vmalloc_huge(). (Christoph Hellwig) > > 2. Add module_alloc_huge(). (Christoph Hellwig) > > 3. Add Fixes tag and Link tag. (Thorsten Leemhuis) > > > > Enabling HAVE_ARCH_HUGE_VMALLOC on x86_64 and use it for bpf_prog_pack has > > caused some issues [1], as many users of vmalloc are not yet ready to > > handle huge pages. To enable a more smooth transition to use huge page > > backed vmalloc memory, this set replaces VM_NO_HUGE_VMAP flag with an new > > opt-in flag, VM_ALLOW_HUGE_VMAP. More discussions about this topic can be > > found at [2]. > > > > Patch 1 removes VM_NO_HUGE_VMAP and adds VM_ALLOW_HUGE_VMAP. > > Patch 2 uses VM_ALLOW_HUGE_VMAP in bpf_prog_pack. > > > > [1] https://lore.kernel.org/lkml/20220204185742.271030-1-song@kernel.org/ > > [2] https://lore.kernel.org/linux-mm/20220330225642.1163897-1-song@kernel.org/ > > > > Song Liu (3): > > vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP > > module: introduce module_alloc_huge > > bpf: use vmalloc with VM_ALLOW_HUGE_VMAP for bpf_prog_pack > > > > arch/Kconfig | 6 ++---- > > arch/powerpc/kernel/module.c | 2 +- > > arch/s390/kvm/pv.c | 2 +- > > arch/x86/kernel/module.c | 21 +++++++++++++++++++ > > include/linux/moduleloader.h | 5 +++++ > > include/linux/vmalloc.h | 4 ++-- > > kernel/bpf/core.c | 9 +++++---- > > kernel/module.c | 8 ++++++++ > > Please use modules-next [0] as that has queued up changes which change > kernel/module.c quite a bit. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-next We are hoping to ship this set to fix some issues with 5.18. So I guess it shouldn't go through modules-next branch? Would this work for you? We are adding a new API module_alloc_huge(), so it shouldn't break existing features. Thanks, Song