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 D18ABC352A1 for ; Wed, 7 Dec 2022 19:27:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 751908E0003; Wed, 7 Dec 2022 14:27:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 702128E0001; Wed, 7 Dec 2022 14:27:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CB178E0003; Wed, 7 Dec 2022 14:27:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4F5238E0001 for ; Wed, 7 Dec 2022 14:27:14 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 05F28140CD3 for ; Wed, 7 Dec 2022 19:27:14 +0000 (UTC) X-FDA: 80216493588.24.ACD2533 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 9D4FE140005 for ; Wed, 7 Dec 2022 19:27:12 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dUGdL7xn; spf=pass (imf26.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670441232; 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=ffSxwpCqrALL02p7Ax/IHHfqT4ZAyzoXtFcQaPmUkDQ=; b=mJu7cotu2TzUxUDAvCY5XxV1dJ3LDKDg/e3zKUaB/M76e4hW88inpUplxlsO+DsGQ1zu46 KrTpUsB2swG585fWZfbm9lQyy8GSm6x4sq5DgZCiHOasR8D3GddbUD3aYH8bxnCMx7kk1V 6pFQhm51uldQE/+RIrRnIy2AWZ9BFNc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dUGdL7xn; spf=pass (imf26.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670441232; a=rsa-sha256; cv=none; b=CJAKsEPM0IlkotjUfm5/w7Up1wSFTWSJu2NySUaUpc1/Ys00Mm3R3SCdzFZCJ+tApRgf7L 7uikYolx0j9ySgK6CaxwCLGm9tLV3PLZIXiIqZanOZ7dgAEDsXwhR4sPxnso5jgHdGMOwz hTjrKh4JQ6ClACdduE+X3WKnBsOesaQ= 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 dfw.source.kernel.org (Postfix) with ESMTPS id C3B6D61BCB for ; Wed, 7 Dec 2022 19:27:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 321D7C433B5 for ; Wed, 7 Dec 2022 19:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670441231; bh=5FkmKMcgD621lYtSY9QcdA9W2/ZLeGsK+iiW5+lfbKk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dUGdL7xnr5ubERiyhjNyzE40gYFVdDe741GFRufq4sPsTHLmB7na1t0ZX0wp/kQI0 fQyOslMGHy1nNVqFp8vxejmO38urzA+hrxMBnPdOSzjxnFA7xQovojkLjJqTgEPruw T202vzwpe7D/E1zL9iVMMi2oGEqKtpqFB8IpUS05IPxQ7qXB+HLe89jOK60pxIs6Q/ V4k+Ruz94wqP8paAzNtV+x1AhuEMtDHowQ5JMOSmsXwRkP76+tgrBvqNe3YDHliBHx DdeJQlLod08CMdNt7eQSz2yLl1XIn69REzXnI//a9UESIe2DaT8PW75+kdCSUpS1ox fw5DsPWoM21cg== Received: by mail-ej1-f43.google.com with SMTP id bj12so16310997ejb.13 for ; Wed, 07 Dec 2022 11:27:11 -0800 (PST) X-Gm-Message-State: ANoB5pmFyuMx68TnKKYed38riS/sL+AFZhRJ5ZNpOm2nCR7EEE2xj4Fd XEg8ttHCNmpvXL2ugkFuU2cJ8qjiTSuCjLG24cs= X-Google-Smtp-Source: AA0mqf4D7uENP5j+VoEifnebjfv7JhZ4uwh8K+Lw1iyWJW9ee9FSiBI8qcd7cvWmmBoqwiIuQ76VE1Tegt/i0WRZYzk= X-Received: by 2002:a17:907:7e86:b0:7af:bc9:5e8d with SMTP id qb6-20020a1709077e8600b007af0bc95e8dmr1072278ejc.3.1670441229415; Wed, 07 Dec 2022 11:27:09 -0800 (PST) MIME-Version: 1.0 References: <87v8mvsd8d.ffs@tglx> <87k03ar3e3.ffs@tglx> <878rjqqhxf.ffs@tglx> <87v8mndy3y.ffs@tglx> In-Reply-To: <87v8mndy3y.ffs@tglx> From: Song Liu Date: Wed, 7 Dec 2022 11:26:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: Thomas Gleixner Cc: bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org, x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org, mcgrof@kernel.org, Dinh Nguyen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9D4FE140005 X-Stat-Signature: fzoxfqbf9rxg9r68zy5gbeofnu3p5e8n X-Rspam-User: X-Spamd-Result: default: False [3.09 / 9.00]; IRL_BL_25(2.00)[52.25.139.140:received]; SUBJECT_HAS_UNDERSCORES(1.00)[]; BAD_REP_POLICIES(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAYES_HAM(-0.01)[46.71%]; R_SPF_ALLOW(0.00)[+a:dfw.source.kernel.org]; RCPT_COUNT_TWELVE(0.00)[12]; DMARC_POLICY_ALLOW(0.00)[kernel.org,none]; R_DKIM_ALLOW(0.00)[kernel.org:s=k20201202]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[kernel.org:+]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; ARC_NA(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Server: rspam08 X-HE-Tag: 1670441232-176241 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 Thomas, On Wed, Dec 7, 2022 at 7:36 AM Thomas Gleixner wrote: > [...] > > Survey of the 11 architecture specific module_alloc(). They basically do > > the following magic: > > > > 1. Modify MODULES_VADDR and/or MODULES_END. There are multiple > > reasons behind this, some arch does this for KASLR, some other archs > > have different MODULES_[VADDR|END] for different processors (32b vs. > > 64b for example), some archs use some module address space for other > > things (i.e. _exiprom on arm). > > > > Archs need 1: x86, arm64, arm, mips, ppc, riscv, s390, loongarch, > > sparc > > All of this is pretty much a boot time init decision, right? Yeah, all of these are boot time or compile time decisions. > > > 2. Use kasan_alloc_module_shadow() > > > > Archs need 2: x86, arm64, s390 > > There is nothing really architecture specific, so that can be part of > the core code, right? Right, kasan_free_module_shadow() is called from vmalloc.c, so the alloc one can do the same. > > > 3. A secondary module address space. There is a smaller preferred > > address space for modules. Once the preferred space runs out, allocate > > memory from a secondary address space. [...] > > > 6. nios2 uses kmalloc() for modules. Based on the comment, this is > > probably only because it needs different MODULES_[VADDR|END]. > > It's a horrible hack because they decided to have their layout: > > VMALLOC_SPACE 0x80000000 > KERNEL_SPACE 0xC0000000 > > and they use kmalloc because CALL26/PCREL26 cannot reach from 0x80000000 > to 0xC0000000. That's true, but broken beyond repair. > > Making the layout: > > VMALLOC_SPACE 0x80000000 > MODULE_SPACE 0xBE000000 == 0xC0000000 - (1 << 24) (32M) > or > MODULE_SPACE 0xBF000000 == 0xC0000000 - (1 << 24) (16M) > KERNEL_SPACE 0xC0000000 > > would have been too obvious... Yeah, I was thinking about something like this. > > > I think we can handle all these with a single module_alloc() and a few > > module_arch_* functions(). [...] > > /** > * struct mod_alloc_type - Parameters for module allocation type > * @mapto_type: The type to merge this type into, if different > * from the actual type which is configured here. > * @flags: Properties > * @granularity: The allocation granularity (PTE/PMD) > * @alignment: The allocation alignment requirement > * @start: Array of address space range start (inclusive) > * @end: Array of address space range end (inclusive) > * @pgprot: The page protection for this type > * @fill: Function to fill allocated space. If NULL, use memcpy() > * @invalidate: Function to invalidate allocated space. If NULL, use memset() > * > * If @granularity > @alignment the allocation can reuse free space in > * previously allocated pages. If they are the same, then fresh pages > * have to be allocated. > */ > struct mod_alloc_type { > unsigned int mapto_type; > unsigned int flags; > unsigned int granularity; > unsigned int alignment; > unsigned long start[MOD_MAX_ADDR_SPACES]; > unsigned long end[MOD_MAX_ADDR_SPACES]; > pgprot_t pgprot; > void (*fill)(void *dst, void *src, unsigned int size); > void (*invalidate)(void *dst, unsigned int size); > }; Yeah, this is a lot better than arch_ functions. We probably want two more function pointers here: int (*protect)(unsigned long addr, int numpages); int (*unprotect)(unsigned long addr, int numpages); These two functions will be NULL for archs that support text_poke; while legacy archs use them for set_memory_[ro|x|rw|nx]. Then, I think we can get rid of VM_FLUSH_RESET_PERMS. [...] Everything else makes perfect sense. Thanks! I think I am ready to dive into the code and prepare the first RFC/PATCH. Please let me know if there is anything we should discuss/clarify before that. Best, Song