Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1365479rda; Mon, 23 Oct 2023 10:14:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHuqPOZstkL61bHSWplWi8uOi0Vv6Yqy8lLXt+qKj5oZWsnLsL7k5qnUhda3wPTLan9PO0b X-Received: by 2002:a17:902:f283:b0:1c5:ce3c:c399 with SMTP id k3-20020a170902f28300b001c5ce3cc399mr9949750plc.39.1698081286173; Mon, 23 Oct 2023 10:14:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698081286; cv=none; d=google.com; s=arc-20160816; b=CS02UynKDaH2R1hkAuYiszVhzMFlUFFj6bngp21WL2v+xafi7thvssF/ZSgrVs3R1T K40OaTvlbyrtGpfz7dJcdDuiwh6rQo8c2K5ludlH6nIaaYY4S1b4ASSNOrAQGBoIrVbX XI1/LwxlHyMVHJVZYGp4MbD1+AzJC3KQ6/05bTD9IsGVWwp8c/9hHUx4ALF/8z5SPqZ0 DUgNKOwUjBQ2lO34ZH79QYJqJ57kvLinNaDP6cNAUUyYs4y/eomsr6jvJcDxgcUGbQAT mgRrqGZDdL+wJncMj1FpscARRKG8AQNH7MARkke/GjXJKHDQN2HrOuVUeeoscfA3xepl Jtcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=lszXnBZG7oAR0TTZK6GVqzWKnHsbtNrO1oMs7TR8VwI=; fh=OJK98ATgFJmfCN0gRmseDUU5URm5/2Pk0J7JwopS/Jo=; b=mQbYMJmQNLYPSDS7vAFLJNYNLZ2ApJWroGYlRiBUywzWNC0wO00w2nfjM5BxVlCxY3 DDEb4QexTnmjx5vUwSX5tRulatv4icwsf+Kx01K4gBQYXCZOWNtC1wUQ+jATMJth99x3 KTYIen0ZQ+mAcOzh0rIMKWCU+U3LnpxIe0rdHO19pehWDzjsNQt0R5jTPQHEaL3jArD7 jSL3B5L80QUHVJsz3qGOqu3VuxceVwyO2XYj4gGnqzoGi4BPCYEL7DomAy/gDtuN4WOh 68pCT/HnEDL0JZuBbvQQFNjyGibYHGvuxPto2T1BQfupYaQqLOX4EbzinbKaTcD6aK2b TP+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MeuEwtvu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id k15-20020a170902c40f00b001a6ef92d441si7254442plk.599.2023.10.23.10.14.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 10:14:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MeuEwtvu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 8FB4C805E13E; Mon, 23 Oct 2023 10:14:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230055AbjJWROe (ORCPT + 99 others); Mon, 23 Oct 2023 13:14:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjJWROc (ORCPT ); Mon, 23 Oct 2023 13:14:32 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08BBF94; Mon, 23 Oct 2023 10:14:31 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43161C433C9; Mon, 23 Oct 2023 17:14:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698081270; bh=Ja8s9hHWNsMl9rR/A2vkVRwGBByDHecu9TUfTmLK5O0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MeuEwtvuDFO5yp5iwwuVEJNzg9RfG0g2iSphmorTs1YHktZPSgAIBmOgSnoaQJdHm nUlWIMj2sV40TRQksuLqdyoEUZOrZ4YgskSrGgA2/nhb9IFL78IFLLm5ChkY8qJxOI XvSk9ecB7rzX1Id68w7pVTn+QD7K44RzxoL0JXDRTA8j3sh2U4yTDlfwo97LvPAH00 RUnsGssWWAdudZuWTwU1hLYa0ovrTsWm97cFrfjCEL0C5VQBb75ldMMm5wnopS8rdo ma5otrvqzXBMC9YyKDYNnhopzPnGbtq133bDGxB7c+u2v5Gw+ZIgVNda5UvccMxt+p Sq/U+bn87cRzw== Date: Mon, 23 Oct 2023 18:14:20 +0100 From: Will Deacon To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Andrew Morton , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Song Liu , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v3 04/13] mm/execmem, arch: convert remaining overrides of module_alloc to execmem Message-ID: <20231023171420.GA4041@willie-the-truck> References: <20230918072955.2507221-1-rppt@kernel.org> <20230918072955.2507221-5-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230918072955.2507221-5-rppt@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 23 Oct 2023 10:14:43 -0700 (PDT) Hi Mike, On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Extend execmem parameters to accommodate more complex overrides of > module_alloc() by architectures. > > This includes specification of a fallback range required by arm, arm64 > and powerpc and support for allocation of KASAN shadow required by > arm64, s390 and x86. > > The core implementation of execmem_alloc() takes care of suppressing > warnings when the initial allocation fails but there is a fallback range > defined. > > Signed-off-by: Mike Rapoport (IBM) > --- > arch/arm/kernel/module.c | 38 ++++++++++++--------- > arch/arm64/kernel/module.c | 57 ++++++++++++++------------------ > arch/powerpc/kernel/module.c | 52 ++++++++++++++--------------- > arch/s390/kernel/module.c | 52 +++++++++++------------------ > arch/x86/kernel/module.c | 64 +++++++++++------------------------- > include/linux/execmem.h | 14 ++++++++ > mm/execmem.c | 43 ++++++++++++++++++++++-- > 7 files changed, 167 insertions(+), 153 deletions(-) [...] > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > index dd851297596e..cd6320de1c54 100644 > --- a/arch/arm64/kernel/module.c > +++ b/arch/arm64/kernel/module.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -108,46 +109,38 @@ static int __init module_init_limits(void) > > return 0; > } > -subsys_initcall(module_init_limits); > > -void *module_alloc(unsigned long size) > +static struct execmem_params execmem_params __ro_after_init = { > + .ranges = { > + [EXECMEM_DEFAULT] = { > + .flags = EXECMEM_KASAN_SHADOW, > + .alignment = MODULE_ALIGN, > + }, > + }, > +}; > + > +struct execmem_params __init *execmem_arch_params(void) > { > - void *p = NULL; > + struct execmem_range *r = &execmem_params.ranges[EXECMEM_DEFAULT]; > > - /* > - * Where possible, prefer to allocate within direct branch range of the > - * kernel such that no PLTs are necessary. > - */ Why are you removing this comment? I think you could just move it next to the part where we set a 128MiB range. > - if (module_direct_base) { > - p = __vmalloc_node_range(size, MODULE_ALIGN, > - module_direct_base, > - module_direct_base + SZ_128M, > - GFP_KERNEL | __GFP_NOWARN, > - PAGE_KERNEL, 0, NUMA_NO_NODE, > - __builtin_return_address(0)); > - } > + module_init_limits(); Hmm, this used to be run from subsys_initcall(), but now you're running it _really_ early, before random_init(), so randomization of the module space is no longer going to be very random if we don't have early entropy from the firmware or the CPU, which is likely to be the case on most SoCs. > > - if (!p && module_plt_base) { > - p = __vmalloc_node_range(size, MODULE_ALIGN, > - module_plt_base, > - module_plt_base + SZ_2G, > - GFP_KERNEL | __GFP_NOWARN, > - PAGE_KERNEL, 0, NUMA_NO_NODE, > - __builtin_return_address(0)); > - } > + r->pgprot = PAGE_KERNEL; > > - if (!p) { > - pr_warn_ratelimited("%s: unable to allocate memory\n", > - __func__); > - } > + if (module_direct_base) { > + r->start = module_direct_base; > + r->end = module_direct_base + SZ_128M; > > - if (p && (kasan_alloc_module_shadow(p, size, GFP_KERNEL) < 0)) { > - vfree(p); > - return NULL; > + if (module_plt_base) { > + r->fallback_start = module_plt_base; > + r->fallback_end = module_plt_base + SZ_2G; > + } > + } else if (module_plt_base) { > + r->start = module_plt_base; > + r->end = module_plt_base + SZ_2G; > } > > - /* Memory is intended to be executable, reset the pointer tag. */ > - return kasan_reset_tag(p); > + return &execmem_params; > } > > enum aarch64_reloc_op { [...] > diff --git a/include/linux/execmem.h b/include/linux/execmem.h > index 44e213625053..806ad1a0088d 100644 > --- a/include/linux/execmem.h > +++ b/include/linux/execmem.h > @@ -32,19 +32,33 @@ enum execmem_type { > EXECMEM_TYPE_MAX, > }; > > +/** > + * enum execmem_module_flags - options for executable memory allocations > + * @EXECMEM_KASAN_SHADOW: allocate kasan shadow > + */ > +enum execmem_range_flags { > + EXECMEM_KASAN_SHADOW = (1 << 0), > +}; > + > /** > * struct execmem_range - definition of a memory range suitable for code and > * related data allocations > * @start: address space start > * @end: address space end (inclusive) > + * @fallback_start: start of the range for fallback allocations > + * @fallback_end: end of the range for fallback allocations (inclusive) > * @pgprot: permissions for memory in this address space > * @alignment: alignment required for text allocations > + * @flags: options for memory allocations for this range > */ > struct execmem_range { > unsigned long start; > unsigned long end; > + unsigned long fallback_start; > + unsigned long fallback_end; > pgprot_t pgprot; > unsigned int alignment; > + enum execmem_range_flags flags; > }; > > /** > diff --git a/mm/execmem.c b/mm/execmem.c > index f25a5e064886..a8c2f44d0133 100644 > --- a/mm/execmem.c > +++ b/mm/execmem.c > @@ -11,12 +11,46 @@ static void *execmem_alloc(size_t size, struct execmem_range *range) > { > unsigned long start = range->start; > unsigned long end = range->end; > + unsigned long fallback_start = range->fallback_start; > + unsigned long fallback_end = range->fallback_end; > unsigned int align = range->alignment; > pgprot_t pgprot = range->pgprot; > + bool kasan = range->flags & EXECMEM_KASAN_SHADOW; > + unsigned long vm_flags = VM_FLUSH_RESET_PERMS; > + bool fallback = !!fallback_start; > + gfp_t gfp_flags = GFP_KERNEL; > + void *p; > > - return __vmalloc_node_range(size, align, start, end, > - GFP_KERNEL, pgprot, VM_FLUSH_RESET_PERMS, > - NUMA_NO_NODE, __builtin_return_address(0)); > + if (PAGE_ALIGN(size) > (end - start)) > + return NULL; > + > + if (kasan) > + vm_flags |= VM_DEFER_KMEMLEAK; Hmm, I don't think we passed this before on arm64, should we have done? Will