From nobody Thu Apr 2 18:47:37 2026 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D960B3CE493 for ; Fri, 27 Mar 2026 08:00:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774598466; cv=none; b=KEzaETCCTtfGs97flz/l/TFrsLI1DOb4e/MZegqKdQ0t9JgyFgEq9vRv/MmFDHkAlWNecy6dSqN094h1lyoR2nXFnggUr54zBztivR1vSn+O4yJYWAVv2uhdNy6aTUWndRNUzd/NJS7ZqhEhsHhXQbNBMbyIPlIdBQMs6R2gPAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774598466; c=relaxed/simple; bh=VuK/A2SKkIB8gq+5+JMkruh64JklcZWA+VF4xG65caU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uCRMzzf09vYzGoacr7S1B7H1NXhf9Wzb8+ntXEOnTj7WTbShbZdXL5qxDUOwjy5DPCmQq4YbEuEkrZR68NtSPpcq32whBzlFTDjjUuXkHBaSbHLNnYk2pJ0C5F5XOlstQ1yRRbyHJEHb9g42ozZeXKv0O6k7qkkAW0GahZ9VnJU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=PxZ/FGS1; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="PxZ/FGS1" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-486b96760easo19677825e9.2 for ; Fri, 27 Mar 2026 01:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1774598457; x=1775203257; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/maIRRXWsco2YLlNLQIg+54XR4CJ2LAx0k8sLQQpIyQ=; b=PxZ/FGS1/Sq0/D0Dz/6gs05dbL2ERBXFYpjj9uyX39yEEB2PRCoKjvS4pGqYJXzPsD n4cDhvpGAcjJ1Oaly2VG2crQUE/ToXUQW1SFkcnK7aCuJRyEP/fjNYIB3JmxZLRcEY9S Q/w3pMZ1bAe0XfZ+O5vMhXV40/nthHFq7WYcSDOt16oHglBQDQcHL2KaA4sxdzY9zeOA 6uQP9f8OUTNQUeCwWouzER6OWakeWO12OymkchDkXFS8HN+QxvdC/hcoluCdgawDFueM ge4Z1AjoJSeqM0rdPH6pS1Koycr1tZqpJWoU5+A7TGENcIdUVI1aD95BcFEWzaZ3Vcek kFcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774598457; x=1775203257; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/maIRRXWsco2YLlNLQIg+54XR4CJ2LAx0k8sLQQpIyQ=; b=TSacIcNh25/Tess/1ZdhXIpJd7DcCVli5AF9VftWdvewL4DvuFVajSZ2fBNA4Vvy8R TZ1MxKwvNVoURs2dr2HCfPvTIxnwv9BeCqZBRaXtrX7c2WQihp+JRQFX7AV3jWTyJiSR U1cw+g8W2RqSzmrpf06WuzCjvWlybWaGkTCE0npHOF+rU5ntR2CnEqrjRjRcTI+a0GG9 v5QXReYML81DH7vRMRoY4BH47Mc+/4Hs9pZFE7BsdNDRhsxl0rdYleaUgrJP0oKGQTw4 R6m/LwyucTWmXpSsOdidISSDPI/N8Ndf+PDpnK0M02vY2clEvtbya/JmyOzq+miUJpwY Z0UQ== X-Forwarded-Encrypted: i=1; AJvYcCWSWLM9sI0IgVjF9VUcn3R2QfUG+AJrJ9Lxw9z+9jGA2E9xJnDIYmN7aaa7IYK2uV+SuuHhjaCklu4YAfw=@vger.kernel.org X-Gm-Message-State: AOJu0Yyudt11OHRf0029+XfaoBzNdo+gFPW3x5IoLDoxVI2+sKV5jhx6 gqBDsUYjx7pGtjvIKpXOX3ckrIwFtHbVAFACqwC3dh3VkU1QrraKofr+EHUOTCgTrI4= X-Gm-Gg: ATEYQzxytkcdgDAGURln1KckBNv6RGk+miUiz6NFdnERyj2kT4ZRotin/R6DehW5/ff k2AN5x/vwjBycpr8d+NXKAUL8SytHSsShlN6YNY4qn3PsrNHaFMtN6Bq6awr4hdOdp3CEm4voyc HsmzEFr/Zuub8E+AVCODx5gwc88Tqf533Le5qd4YPAYe1P+3vGFIJgmM689Q2YRc1n1WwnUdoAq nu8OcayJWaV3/6CfLVam/oNclFcwnmbAoXg8DHiN2GFtPiPWRX4D/+KidsLfvsh3TTb42ZjtELw YuivhflMIraV96paLTUVZGvK2EboF2pK+X+yBLdHk3GkY9Vr+z8RmS7FWlH1L+DWSGbJAqI+mJa ajblK6jQ2OoQrer63Ja0MFln4MmHqzBGjr0EBfaUvAEKQUEb5ZYrhznu4Xlg/XMtb88/R+ZkmTZ 4x0L5FB8tn4ocVl1D0Q6fXnJRE3LJATHyVgaLTKJGo X-Received: by 2002:a05:600c:828a:b0:487:338:b4df with SMTP id 5b1f17b1804b1-48727d8818cmr22261095e9.15.1774598457203; Fri, 27 Mar 2026 01:00:57 -0700 (PDT) Received: from zovi.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48725fc4827sm12089735e9.11.2026.03.27.01.00.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 01:00:56 -0700 (PDT) From: Petr Pavlu To: Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sami Tolvanen Cc: Alexandre Ghiti , Luis Chamberlain , Petr Pavlu , Daniel Gomez , Aaron Tomlin , Joe Lawrence , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-riscv@lists.infradead.org, linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/4] module, arm64: force sh_addr=0 for arch-specific sections Date: Fri, 27 Mar 2026 08:59:01 +0100 Message-ID: <20260327080023.861105-3-petr.pavlu@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com> References: <20260327080023.861105-1-petr.pavlu@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When linking modules with 'ld.bfd -r', sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the resulting .ko files. Relocatable objects are expected to have sh_addr=3D0 f= or all sections. Non-zero addresses are confusing in this context, typically worse compressible, and may cause tools to misbehave [1]. Force sh_addr=3D0 for all arm64-specific module sections. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33958 [1] Signed-off-by: Petr Pavlu --- Note that the definition of .text.hot hasn't matched any input sections since commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros"), and even before that with CONFIG_LTO_CLANG=3Dy. The preceding comment also explains that the directive is necessary to merge section groups. However, this approach seems suboptimal. A better method would be to link modules using --force-group-allocation to retain only one copy of each group. I plan to look at this separately. --- arch/arm64/include/asm/module.lds.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/module.lds.h b/arch/arm64/include/asm/m= odule.lds.h index fb944b46846d..0b3aacd22c59 100644 --- a/arch/arm64/include/asm/module.lds.h +++ b/arch/arm64/include/asm/module.lds.h @@ -14,7 +14,7 @@ SECTIONS { * directive to force them into a single section and silence the * warning. */ - .text.hot : { *(.text.hot) } + .text.hot 0 : { *(.text.hot) } #endif =20 #ifdef CONFIG_UNWIND_TABLES @@ -22,6 +22,6 @@ SECTIONS { * Currently, we only use unwind info at module load time, so we can * put it into the .init allocation. */ - .init.eh_frame : { *(.eh_frame) } + .init.eh_frame 0 : { *(.eh_frame) } #endif } --=20 2.53.0