From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 B24FBC8EB for ; Thu, 8 Jan 2026 21:59:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767909570; cv=none; b=m5GP9kkQ1D5RH6GFeh3/XZw59C/hA3CFWYCngmtvk2oNf/Ysws+UZ9TEZyBRHetp9EBXtM3xiwb8YFftYsHHFqggAF/SUO3uh1tyXY2AHVMRKEinjvw3EfcrFxQ6RizLP0DvbLTQhjLIr6ZyFCpFdiuJuk1t/ssHpjnhinka8jA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767909570; c=relaxed/simple; bh=n1FED02/isBAo+FWI/3dEX+dCgZVjigO1tqcVEgguH8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JRvRN/IPzlZq1IDPUEH/Y6nc4ckL/VW4ixAbzOuTwm1wUhDmTLrUPXvItFaYox75C3lvrCrD/5WDQGqZBDmW5dNLA5x1WsJIonoxglq5DpYFWvH5ihfC/wgHgyHU0WL1Vc6weWJWj5iJJM7ML5K3ulhZiCZEgFREquh3NybKq8k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=aoDmiWVO; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="aoDmiWVO" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2a35ae38bdfso9875ad.1 for ; Thu, 08 Jan 2026 13:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767909568; x=1768514368; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=12l6ZAXCgEdEnz5LzVUFTc4+PbrdiKV8uTVIJz7Wh0g=; b=aoDmiWVOXhrZxxwP1Fqyrvqn37Mk5Rw9UqgKsWr3pV0IwUF5nSDtWDyGNnC/9wJHrK LWEkYe3mrRlN/Vpk7jOFa367Qi7wY0teOrHSIo7/TBi2495AXvMxm2/EDEnhzg6TfycK h2ijkw7pfCUNjoXA2Hddc8NRupHYyNuULS3SABX8Wqr18+yxGUKYYTsOnayV3mOXN2Am m6V/ryaOTEnmZFYEyXBUp2iQWVxLpXXUxxW8w0EmvK4qT4NvSgGwshWiZCIIT6gTzDn2 kCSwq/c7U3ApfILuzNNzZZvUShKfPEpkxSR7JJ+F3sKSpAqnQohZk+yHMT9t8Mt9Ui4A t74w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767909568; x=1768514368; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=12l6ZAXCgEdEnz5LzVUFTc4+PbrdiKV8uTVIJz7Wh0g=; b=PI+4APQd4CYb4/OfZ2P5XLPILCYxruFn0UO3Q98pgjF/rlKgFkH94WEPSFgeTAyBdv IFWssXw4WyQVfLYdZ9ntDA5Jkc7h6mK3tkcYIzGuGurbtvSEQVG/sQA5kjIJFkpwUkUX xEHRPC8CtpEgT3WfITg9uWkXeRhJe5l9HA77uq68X+gPdlCFgF3+BbEgkN3C2KUH1BIe 4RtOEODJEJcZqsAQqLp/fOwBE7NKCveUotzbrysdesQ9ti75pX0/nynEQWSMbIM8mHs1 KczRDfmZQ2vDiFHoSTnagknet+50k43oFOwZjiax9nG05XayAnunDJaBMln+/LMZTSxo ezOw== X-Forwarded-Encrypted: i=1; AJvYcCURPxeTZQ32uL/sDEK5aLESThrUAAwEaFRHU8sUtN5+EoNS1Z93QHGWqJHEW3bCYyacsYeslEFkDJGt00E=@vger.kernel.org X-Gm-Message-State: AOJu0YyLA4Qv8cp1sDR6Ng8ryzLt8wsXHuBsYFZ6KwrHt4VGNGtRsUag jsTnO7sM9RcGSAyhCeAa/sEsLOwijyHO0ZI1/G6wAEeGvxswfbQFQHkMShr4TWlGwA== X-Gm-Gg: AY/fxX6qPvNAybSIGgVujWZFv8db9orJ053DwtQ4GZ15x9B/UiPjR9zoGgxH37peAMd 5h6LfpgVCfLQgfxrgmfbgU1mQfG4qh2+Nxlf4A7GmbyidVRDqMz3CZX4wXH8mgbTYngGKpoc7Ru uY6URZzhC4xr+UPY5SEd+4iv55LguKbGNzsGko1mp55mcoZLjwY8zaq/F+pn+bMSFMebn23/lDy q3p4vsDNG4ZeNFsOtNy16dVC327to9ahDc5JRtJTTYr3nHpkfy/e38uWkwA/u1ybkwJYo4+BKhG Fj10ziwc0xT6pkPkpD9wH4LAXoomFW15ANr6ekngK53sCiqeFKfBlR9yXPDk5sNopAvRZ+P5cf3 cR1MBFHlMFvKxP8uFyxWmz1Rb2Wjj0cPspXPe5+1olYo/g+Uws1xK6wOOp1+TCHg1pSl5i3xs4C NpUm5naT1rXz5qtz9o8lupsMFLOdW1oPp2eQK8Sh4mAbrsBpeZZg== X-Received: by 2002:a17:902:db02:b0:2a1:35df:250f with SMTP id d9443c01a7336-2a40a985c51mr369485ad.15.1767909567697; Thu, 08 Jan 2026 13:59:27 -0800 (PST) Received: from google.com (210.53.125.34.bc.googleusercontent.com. [34.125.53.210]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a3e3cd3632sm88131445ad.95.2026.01.08.13.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 13:59:27 -0800 (PST) Date: Thu, 8 Jan 2026 21:59:21 +0000 From: Carlos Llamas To: Will Deacon Cc: Ard Biesheuvel , Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org, Petr Mladek , Miroslav Benes , Joe Lawrence , live-patching@vger.kernel.org, Song Liu , laokz , Jiri Kosina , Marcos Paulo de Souza , Weinan Liu , Fazla Mehrab , Chen Zhongjin , Puranjay Mohan , Dylan Hatch , Peter Zijlstra , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sami Tolvanen , kernel-team@android.com Subject: Re: [PATCH v4 02/63] vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros Message-ID: References: <97d8b7710a8f5389e323d0933dec68888fec5f1f.1758067942.git.jpoimboe@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jan 06, 2026 at 10:46:33PM +0000, Will Deacon wrote: > On Sat, Dec 20, 2025 at 04:25:50PM +0000, Carlos Llamas wrote: > > On Wed, Sep 17, 2025 at 09:03:10AM -0700, Josh Poimboeuf wrote: > > > TEXT_MAIN, DATA_MAIN and friends are defined differently depending on > > > whether certain config options enable -ffunction-sections and/or > > > -fdata-sections. > > > > > > There's no technical reason for that beyond voodoo coding. Keeping the > > > separate implementations adds unnecessary complexity, fragments the > > > logic, and increases the risk of subtle bugs. > > > > > > Unify the macros by using the same input section patterns across all > > > configs. > > > > > > This is a prerequisite for the upcoming livepatch klp-build tooling > > > which will manually enable -ffunction-sections and -fdata-sections via > > > KCFLAGS. > > > > > > Cc: Heiko Carstens > > > Cc: Vasily Gorbik > > > Cc: Alexander Gordeev > > > Signed-off-by: Josh Poimboeuf > > > --- > > > include/asm-generic/vmlinux.lds.h | 40 ++++++++++--------------------- > > > scripts/module.lds.S | 12 ++++------ > > > 2 files changed, 17 insertions(+), 35 deletions(-) > > [...] > > > I'm seeing some KP when trying to load modules after this change. I > > believe there is some sort of incompatibility with the SCS (Shadow Call > > Stack) code in arm64? The panic is always on __pi_scs_handle_fde_frame: > > > > init: Loading module [...]/drivers/net/wireless/virtual/mac80211_hwsim.ko > > Unable to handle kernel paging request at virtual address ffffffe6468f0ffc > > [...] > > nit: please don't trim the useful stuff when reporting a crash! > > > pc : __pi_scs_handle_fde_frame+0xd8/0x15c > > lr : __pi_$x+0x74/0x138 > > sp : ffffffc08005bb10 > > x29: ffffffc08005bb10 x28: ffffffc081873010 x27: 0000000000000000 > > x26: 0000000000000007 x25: 0000000000000000 x24: 0000000000000000 > > x23: 0000000000000001 x22: ffffffe649794fa0 x21: ffffffe6469190b4 > > x20: 000000000000182c x19: 0000000000000001 x18: ffffffc080053000 > > x17: 000000000000002d x16: ffffffe6469190c5 x15: ffffffe6468f1000 > > x14: 000000000000003e x13: ffffffe6469190c6 x12: 00000000d50323bf > > x11: 00000000d503233f x10: ffffffe649119cb8 x9 : ffffffe6468f1000 > > x8 : 0000000000000100 x7 : 00656d6172665f68 x6 : 0000000000000001 > > x5 : 6372610000000000 x4 : 0000008000000000 x3 : 0000000000000000 > > x2 : ffffffe647e528f4 x1 : 0000000000000001 x0 : 0000000000000004 > > Call trace: > > __pi_scs_handle_fde_frame+0xd8/0x15c (P) > > module_finalize+0xfc/0x164 > > post_relocation+0xbc/0xd8 > > load_module+0xfd4/0x11a8 > > __arm64_sys_finit_module+0x23c/0x328 > > invoke_syscall+0x58/0xe4 > > el0_svc_common+0x80/0xdc > > do_el0_svc+0x1c/0x28 > > el0_svc+0x54/0x1c4 > > el0t_64_sync_handler+0x68/0xdc > > el0t_64_sync+0x1c4/0x1c8 > > Code: 54fffd4c 1400001f 3707ff63 aa0903ef (b85fcdf0) > > Hmm, looks like a translation fault from the load buried here: > > u32 insn = le32_to_cpup((void *)loc); > > in scs_patch_loc(), called from the 'DW_CFA_negate_ra_state' case in > scs_handle_fde_frame(). So presumably 'loc' is bogus. > > Since you replied to this patch, does reverting it fix the problem for > you? Yes, but it is only coincidental. The real issue seems to be with our toolchain. I'll start looking there instead. Sorry for the noise. -- Carlos Llamas