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 97836C433EF for ; Thu, 14 Jul 2022 10:16:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13BF794019E; Thu, 14 Jul 2022 06:16:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EC25940134; Thu, 14 Jul 2022 06:16:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF5DD94019E; Thu, 14 Jul 2022 06:16:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DC559940134 for ; Thu, 14 Jul 2022 06:16:30 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ABA7B1316 for ; Thu, 14 Jul 2022 10:16:30 +0000 (UTC) X-FDA: 79685300940.24.FABA294 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id DC73612007B for ; Thu, 14 Jul 2022 10:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=0Gkk0NC34K+apqrYO+RTe0+nfUNqT3lfjLteCbnILho=; b=UFnSe+fhAVY6yhXjV2wPJ61iZ8 2Zw0OYv0osZnIIxvRy4gbl9Ye5kgg+qtQKMQkvhFyAK32I4SIz8biMp+cQChL4nwYrIOG6C9ex0Ef f8U+9j9tY1bXIkJVNz+BPOChOnGQrY3uTbXPb+H8mB29/YqRxwsKepdNGgjXhQGGRQAiaiCXQXaCR fpHfR8jE+VDhlrnJsDgRZjQMdGT1qeIdRxvz6Re/H0sOAKr8FKrB+YaDbMcUjAbbDYwWHaeq77Jdg /X5bj3osOCoUykMSaOAx17CzfJkkDvSFWE1X4eNNlbC4Qk3E0NHW17ULmCJInK+jjxGJdV7o3rS7d pVljFdig==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBvsy-009HkF-C2; Thu, 14 Jul 2022 10:15:56 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id E144A980120; Thu, 14 Jul 2022 12:10:36 +0200 (CEST) Date: Thu, 14 Jul 2022 12:10:36 +0200 From: Peter Zijlstra To: Song Liu Cc: Song Liu , bpf , lkml , Linux-MM , "linux-modules@vger.kernel.org" , Luis Chamberlain , Steven Rostedt , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Masami Hiramatsu , "naveen.n.rao@linux.ibm.com" , "davem@davemloft.net" , "anil.s.keshavamurthy@intel.com" , "keescook@chromium.org" , "hch@infradead.org" , "dave@stgolabs.net" , "daniel@iogearbox.net" , Kernel Team , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "rick.p.edgecombe@intel.com" , "akpm@linux-foundation.org" Subject: Re: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc_exec which allocates RO+X memory Message-ID: References: <20220713071846.3286727-1-song@kernel.org> <20220713071846.3286727-2-song@kernel.org> <7C927986-3665-4BD6-A339-D3FE4A71E3D4@fb.com> <78A18945-0841-4CCE-8A33-6C09ECBFF7E1@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78A18945-0841-4CCE-8A33-6C09ECBFF7E1@fb.com> ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UFnSe+fh; dmarc=none; spf=none (imf29.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657793790; 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=0Gkk0NC34K+apqrYO+RTe0+nfUNqT3lfjLteCbnILho=; b=LPnV3ZGfd74cGs0mcD1kT/D+z0ecO5ouz7j9rG6H1xu0Gu3+SlS8CPlVrUHkApSGr6bURE HBOe/wFmCR5AiL2NaRAJQW9L/cOG87ByogV2u24E7cFY75h/eRHIInxamocJgIPkOEL50k /D3Vec4DFDfrCNjpVbmjN9PEvqAa8W0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657793790; a=rsa-sha256; cv=none; b=yVeDAqkUCmTc8CTKpZ8JhzoaM70RP1kR36sQdJuCdhmkzx9K2ZLIZqEOSbUNCjUyr/lLAL nHp+mQrDTnfEgMMziFbLiPEkz7qCFNKZehWScslK8Alq91ajbDeSLY80PH8WxXdPn5TYiu RVemHIXLs7BPPoxzLbcJh/4diDW6Lrw= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DC73612007B X-Stat-Signature: f583m9ra4pme3k4ca63niake7ij145bd Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UFnSe+fh; dmarc=none; spf=none (imf29.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org X-Rspam-User: X-HE-Tag: 1657793789-832079 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: On Wed, Jul 13, 2022 at 09:20:55PM +0000, Song Liu wrote: > > > > On Jul 13, 2022, at 1:26 PM, Peter Zijlstra wrote: > > > > On Wed, Jul 13, 2022 at 03:48:35PM +0000, Song Liu wrote: > > > >>> So how about instead we separate them? Then much of the problem goes > >>> away, you don't need to track these 2M chunks at all. > >> > >> If we manage the memory in < 2MiB granularity, either 4kB or smaller, > >> we still need some way to track which parts are being used, no? I mean > >> the bitmap. > > > > I was thinking the vmalloc vmap_area tree could help out there. > > Interesting. vmap_area tree indeed keeps a lot of useful information. > > Currently, powerpc supports CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC, Only PPC32; and it's due to a constraint in their MMU vs page protections. > which leaves module_alloc just for module text. If this works, we get > separation between RO+X and RW memory. What would it take to enable > CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC for x86_64? The VM_TOPDOWN_VMAP flag and ensuring the data and code regions never overlap. Once you have that you can enable it. Specifically the problem is that data needs to be in the s32 immediate range just like code, so we're constrained to the module range. Given that constraint, the easiest solution is to use the different ends of that range.