From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794061361; b=B4tIVV8VsmY5U1BObGIiX+QYQrr7PSy3e7lNKhCaGBhtV4Wj8oJYWamAWKmz0lDHp6rC YxsH26Aj4P4aWJs7nnC1nMi/GncalUyoprtEJTMG1TQawcX2pI4WK3kCX0SXdSz/3E5Lo ZfDaAhedgxFaOqlJvYuO329qdKTCxZRQR8IKLY6Y6jmab05sQWG0Y5r6OvvseGFHdlksk /juWJ35RecL3WdLkY6zHWCbTpCpzNQUaIr1t7B1QyAxRBKkSsrgJTwf/10TokV4AdEba0 0NDrGGJT4Oin84oPjRpqnMn8fSHW3qFa6QtXBcg3D3VH7bQXEONfx1KPtowdakAIcjw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794061361; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=E1zIpUtzS2yXZSzlPNU48U3LB9PuL1N9qNBjftT1qvQ=; b=tGX2X1dYLtSDNr/DbkHH4AActvpYIWdY5FYDPwufrSpVTAZAsUJC/GSlKKbXhpdpJ+yd 1BicMAGr/Z00dgXAuidxUrhBNmg9cJwJ1655KVj9X8ygXotg/9gGUAMQMnX/BafSn+bAr UPOt2if7EW6gEC7JdkknjPkG8Cf4epQZSx2kIzq9w0owsW55yJh/wR7uB6JdDFxxPjbuL vlA8x5+G4Fjsk0MxIUgTtaeGeyo3i5HWmv0OrqLVvFwFf9L8QFI53SA6sJXTik31TnKWD A+eZaKKApBAKYvT15EtH9E5Qfy6bf5doG7a0d2+GgdVNfMcJ5iQ5k9UNEdpFnxHJ9rw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=FlYEliED; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B03F9606A326; Sat, 7 Nov 2026 14:22:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=FlYEliED Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A5AC1F008A3; Sat, 7 Nov 2026 14:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794061360; bh=E1zIpUtzS2yXZSzlPNU48U3LB9PuL1N9qNBjftT1qvQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FlYEliEDkLmMNDoU4ttxoT8gYKwpuki8goobRxEW7bdDTBP1ENwLSDHbFy2ETu6lh vGaUyEEiAseJyPU2Ett4nTmYwCBHc3ImdVpqNzJyWYQ0MbcLpsTmIN49T0I4ac+sNl tr8R0q0b6jw6PeAjJHTcRDjAV0oNnIX/aUoiEO50= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Tiezhu Yang , Huacai Chen , Sasha Levin Subject: [PATCH 6.12 0485/1536] LoongArch: Expand module virtual address space to 2GB Date: Sat, 7 Nov 2026 08:41:41 -0500 Message-ID: <20261107135011.104892851@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134957.653319350@linuxfoundation.org> References: <20261107134957.653319350@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tiezhu Yang [ Upstream commit 18210a104bb97e28c26dc31fd9fc7b5c381fec62 ] The current 256MB module virtual address space is easily exhausted when loading massive graphics drivers such as amdgpu along with the large unstripped symbol tables, resulting in allocation failures of "execmem: unable to allocate memory". Thus, expand the module virtual address space to 2GB while keeping the current normal code model '-mcmodel=normal', rather than using the medium code model '-mcmodel=medium'. This approach avoids the extra performance overhead and larger binary size of forcing every function call into a 2-instruction sequence of 'pcaddu18i + jirl'. Given that individual module code segments rarely exceed 128MB, most jumps remain fast direct calls by using the bl instruction. For the long-distance jumps exceeding the +/-128MB limit, apply_r_larch_b26() emits PLT entries, while signed_imm_check() guarantees the run-time safety by rejecting any out-of-bound instruction offsets. There is still a risk that the distance between .init.text and .text of the same module exceeds 128MB. So we divide the 2GB virtual space to be two sub-regions: the first 256MB is for module text, and the rest is for module data. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen [ sashal: Adapted the hunk context to this tree, where the MODULES_VADDR defines sit outside CONFIG_64BIT and the init guard is plain CONFIG_EXECMEM, leaving the changed lines identical to upstream. ] Signed-off-by: Sasha Levin --- arch/loongarch/include/asm/pgtable.h | 2 +- arch/loongarch/mm/init.c | 17 ++++++++++++++--- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/include/asm/pgtable.h index 8f1df75686e2d..59c5925a78a53 100644 --- a/arch/loongarch/include/asm/pgtable.h +++ b/arch/loongarch/include/asm/pgtable.h @@ -80,7 +80,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]; * still reliably trap. */ #define MODULES_VADDR (vm_map_base + PCI_IOSIZE + (2 * PAGE_SIZE)) -#define MODULES_END (MODULES_VADDR + SZ_256M) +#define MODULES_END (MODULES_VADDR + SZ_2G) /* 256MB for text, rest for data */ #ifdef CONFIG_KFENCE #define KFENCE_AREA_SIZE (((CONFIG_KFENCE_NUM_OBJECTS + 1) * 2 + 2) * PAGE_SIZE) diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c index a6c5fd2df2f6d..9cd297fae9e64 100644 --- a/arch/loongarch/mm/init.c +++ b/arch/loongarch/mm/init.c @@ -247,15 +247,26 @@ pte_t invalid_pte_table[PTRS_PER_PTE] __page_aligned_bss; EXPORT_SYMBOL(invalid_pte_table); #ifdef CONFIG_EXECMEM +#define MODULES_TEXT_START (MODULES_VADDR) +#define MODULES_TEXT_END (MODULES_VADDR + SZ_256M) +#define MODULES_DATA_START (MODULES_VADDR + SZ_256M) +#define MODULES_DATA_END (MODULES_END) + static struct execmem_info execmem_info __ro_after_init; struct execmem_info __init *execmem_arch_setup(void) { execmem_info = (struct execmem_info){ .ranges = { - [EXECMEM_DEFAULT] = { - .start = MODULES_VADDR, - .end = MODULES_END, + [EXECMEM_MODULE_TEXT] = { + .start = MODULES_TEXT_START, + .end = MODULES_TEXT_END, + .pgprot = PAGE_KERNEL, + .alignment = 1, + }, + [EXECMEM_MODULE_DATA] = { + .start = MODULES_DATA_START, + .end = MODULES_DATA_END, .pgprot = PAGE_KERNEL, .alignment = 1, }, -- 2.53.0