From nobody Tue Dec 9 02:53:47 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46E1D265298; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991279; cv=none; b=nUXQIGjDjQ9nXxopUkEXbplx4KrO9QQn1HUq8mjhtBIvk14qKoBpJu8hXiFlD0ly1ETykKDD7AtnsaHDhUuve339rPLr8rwX1fuIsxLOQusc/HYd+H92wx7rTWFGdG3X/UX5yIxkb/KQiudMYzyyNrolZaTMPBBdyzpJ5XXfbYg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991279; c=relaxed/simple; bh=Y/7mQcAensFfGgY+W4uvKcEzdOXEVtHTz6plX/dBmjA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cAFAdsEcb6pR0W+T1mI1fGgTeKTRyY8c+Pungx9yj6gl5BFMZbxM8PHyi+JXhnEYiYaXy6LPwZ8S/EgB3ByE9qr2IndZRILcZi4/Rp8BEHtF6zgICXnzKVYarH82ZQ46begYX/HkbtcHUkXwCfpX4DjcCf0f0Xly79sT79N6v+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lq9xFeEP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Lq9xFeEP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1C48C4CEF1; Wed, 12 Nov 2025 23:47:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762991278; bh=Y/7mQcAensFfGgY+W4uvKcEzdOXEVtHTz6plX/dBmjA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lq9xFeEPLkY/hU5ojQ8Zp6J75pzIma53x7N3f4dk+WXiy3w85XeIpLREFmjrXuccb 4usxFx3c4VS8SqEUkRKmUrvWUdhBwKU5F5C60IlbEKecNwJvr39DBgpmhMJQhPQhm0 jCkweh8buvpPrhpUFY7w2ZiO3ZxPy+FqhMG8VExjuvha3A7yqCNABXE/HVaQZcRyAQ hIwDol35GBnMjC8sWjp+oNaIcwbQVa14cOuVQgwaCtO5ZB4kYcM/GcgLG3sfRysEmA cf4QBvk8TzYwq+NZKaLOqXdPbDugPslKOpxNEdvpsDJPOwl0mKS/WSpn7qtwgIgPdE T5VmaZwcfYxtg== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , live-patching@vger.kernel.org, kernel test robot Subject: [PATCH 1/4] vmlinux.lds: Fix TEXT_MAIN to include .text.start and friends Date: Wed, 12 Nov 2025 15:47:48 -0800 Message-ID: X-Mailer: git-send-email 2.51.1 In-Reply-To: References: 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" Since commit 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN"), the TEXT_MAIN macro uses a series of patterns to prevent the .text.startup[.*] and .text.exit[.*] sections from getting linked into vmlinux runtime .text. That commit is a tad too aggressive: it also inadvertently filters out valid runtime text sections like .text.start and .text.start.constprop.0, which can be generated for a function named start() when -ffunction-sections is enabled. As a result, those sections become orphans when building with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION for arm: arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' f= rom `drivers/usb/host/sl811-hcd.o' being placed in section `.text.start.con= stprop.0' arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' f= rom `drivers/media/dvb-frontends/drxk_hard.o' being placed in section `.tex= t.start.constprop.0' arm-linux-gnueabi-ld: warning: orphan section `.text.start' from `drivers= /media/dvb-frontends/stv0910.o' being placed in section `.text.start' arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' f= rom `drivers/media/pci/ddbridge/ddbridge-sx8.o' being placed in section `.t= ext.start.constprop.0' Fix that by explicitly adding the partial "substring" sections (.text.s, .text.st, .text.sta, etc) and their cloned derivatives. While this unfortunately means that TEXT_MAIN continues to grow, these changes are ultimately necessary for proper support of -ffunction-sections. Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit fro= m TEXT_MAIN") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511040812.DFGedJiy-lkp@int= el.com/ Signed-off-by: Josh Poimboeuf --- include/asm-generic/vmlinux.lds.h | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinu= x.lds.h index 9de1d900fa15..20695bc8f174 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -90,8 +90,9 @@ * Support -ffunction-sections by matching .text and .text.*, * but exclude '.text..*', .text.startup[.*], and .text.exit[.*]. * - * .text.startup and .text.startup.* are matched later by INIT_TEXT. - * .text.exit and .text.exit.* are matched later by EXIT_TEXT. + * .text.startup and .text.startup.* are matched later by INIT_TEXT, and + * .text.exit and .text.exit.* are matched later by EXIT_TEXT, so they mus= t be + * explicitly excluded here. * * Other .text.* sections that are typically grouped separately, such as * .text.unlikely or .text.hot, must be matched explicitly before using @@ -100,16 +101,16 @@ #define TEXT_MAIN \ .text \ .text.[_0-9A-Za-df-rt-z]* \ - .text.s[_0-9A-Za-su-z]* \ - .text.st[_0-9A-Zb-z]* \ - .text.sta[_0-9A-Za-qs-z]* \ - .text.star[_0-9A-Za-su-z]* \ - .text.start[_0-9A-Za-tv-z]* \ - .text.startu[_0-9A-Za-oq-z]* \ + .text.s[_0-9A-Za-su-z]* .text.s .text.s.* \ + .text.st[_0-9A-Zb-z]* .text.st .text.st.* \ + .text.sta[_0-9A-Za-qs-z]* .text.sta .text.sta.* \ + .text.star[_0-9A-Za-su-z]* .text.star .text.star.* \ + .text.start[_0-9A-Za-tv-z]* .text.start .text.start.* \ + .text.startu[_0-9A-Za-oq-z]* .text.startu .text.startu.* \ .text.startup[_0-9A-Za-z]* \ - .text.e[_0-9A-Za-wy-z]* \ - .text.ex[_0-9A-Za-hj-z]* \ - .text.exi[_0-9A-Za-su-z]* \ + .text.e[_0-9A-Za-wy-z]* .text.e .text.e.* \ + .text.ex[_0-9A-Za-hj-z]* .text.ex .text.ex.* \ + .text.exi[_0-9A-Za-su-z]* .text.exi .text.exi.* \ .text.exit[_0-9A-Za-z]* =20 /* --=20 2.51.1 From nobody Tue Dec 9 02:53:47 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABAB92E2EEE; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991279; cv=none; b=ZSUFzGqYh4cxOLTA/8PH96RRyr1y+kc7q2NnE+/uYoQvxr7vvDk13suJ2vaaHKTHJHjJSK1AlHsKunbtXa9O8ejz7EyRVV3TCNC+yta9Jw/GcM2kNCoEMVoss+YHrcsitcXaG0s/dnB3Vnh/rQZucrdmKEhP8pJ3/sOHdSsLIe8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991279; c=relaxed/simple; bh=fZMNYLKw/ZIEvpddN2qoyiEVLFxO+JC5Rp24YJvJXx4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uYxWTgXov7XmCygVMsnbaF7Fxu69Vz8AKtu3vK4RAZV4vIxjZvqkPPe8uhlBexSBi6dpYLpVpuRCXKjkt2OhVx4WawhPH7O+C/gr89LFU4jfzLP+7KtJG299jfnJwFzdhJaf0NC9Z/3o/cNTaYy+qChVT9+h+qhPlYoqdUoHlZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nlN4ilIo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nlN4ilIo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18240C4CEF8; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762991279; bh=fZMNYLKw/ZIEvpddN2qoyiEVLFxO+JC5Rp24YJvJXx4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nlN4ilIoK2f1x4X5ScugHz9euMIL/gdGCYIKpbz1p0+XykN2t01HFvOUfvmZ7SDVE cE6qWt+dL98jG7xvz8t1Q2Jo3sCbRvfzbhxQ4lkZLPUBxEbHMPFp4aI4REtGDA+vq7 H/V25E+b1Ft3r6kMSUOuzJWcNfFH2kZ3wSQ2mdDWCk/lpqY1Mibqqv0Kv4tqFeShq3 uM1ADcX7+5QIJdQiF2bJzyrHF0tBomxnRUhitLrTvmwjGydpXlv8NimqcaNQoup7c6 Hwp0/ukunvMkMj0K3S+D6jyKSA9up5OOq5fnXCN9Or5wBEEMINCMBwCcoih4yQ+mcs GvHAQlwuNVvyA== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , live-patching@vger.kernel.org, Hans de Goede , Mauro Carvalho Chehab Subject: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections Date: Wed, 12 Nov 2025 15:47:49 -0800 Message-ID: X-Mailer: git-send-email 2.51.1 In-Reply-To: References: 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 compiling the kernel with -ffunction-sections (e.g., for LTO, livepatch, dead code elimination, AutoFDO, or Propeller), the startup() function gets compiled into the .text.startup section. In some cases it can even be cloned into .text.startup.constprop.0 or .text.startup.isra.0. However, the .text.startup and .text.startup.* section names are already reserved for use by the compiler for __attribute__((constructor)) code. This naming conflict causes the vmlinux linker script to wrongly place startup() function code in .init.text, which gets freed during boot. Fix that by renaming startup() to ov2722_startup(). Cc: Hans de Goede Cc: Mauro Carvalho Chehab Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit fro= m TEXT_MAIN") Signed-off-by: Josh Poimboeuf --- drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c b/drivers/s= taging/media/atomisp/i2c/atomisp-ov2722.c index c7de7800799a..a4519babf37d 100644 --- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c +++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c @@ -600,7 +600,7 @@ static int ov2722_s_power(struct v4l2_subdev *sd, int o= n) } =20 /* TODO: remove it. */ -static int startup(struct v4l2_subdev *sd) +static int ov2722_startup(struct v4l2_subdev *sd) { struct ov2722_device *dev =3D to_ov2722_sensor(sd); struct i2c_client *client =3D v4l2_get_subdevdata(sd); @@ -662,7 +662,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd, dev->pixels_per_line =3D dev->res->pixels_per_line; dev->lines_per_frame =3D dev->res->lines_per_frame; =20 - ret =3D startup(sd); + ret =3D ov2722_startup(sd); if (ret) { int i =3D 0; =20 @@ -677,7 +677,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd, dev_err(&client->dev, "power up failed, continue\n"); continue; } - ret =3D startup(sd); + ret =3D ov2722_startup(sd); if (ret) { dev_err(&client->dev, " startup FAILED!\n"); } else { --=20 2.51.1 From nobody Tue Dec 9 02:53:47 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C6F82EDD64; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991280; cv=none; b=T9eD76s+65nw6OwX7/a0v8FmDVr6NjcEMlGzD1wEWOaeASJtEnKb+PEOoMoPFVAzbZxAbXR8/SZubc5dhpOhNEIc4c761kdUTv9uP0kfwcobpc2NSl/iDfj4ing1Adt36g6aFE8qd7YVOoJ5dowvl/eG4/pv8lKwBuDbqzYwGDg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991280; c=relaxed/simple; bh=TKK1wNI9iOmIoWNuPxKE/E841R5aLZMCkr7faFg095Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fdor1JiC1mFKDenrXozv3R/lh4hXqybPdrrG4JlM8Vd69CpmpjGMItn9yWjrjX3BYMBcsx4RvS3C4MF0T4bJcDhhTfdZdIFfhGBZ+l8QNSYlYMuycjrxcgwgJBsfP8HyqHJSI7BTdov5pfVK0NqjveTWsvZJOPAxpTAbYFL/DZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nrtzBgrn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nrtzBgrn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D2AFC16AAE; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762991279; bh=TKK1wNI9iOmIoWNuPxKE/E841R5aLZMCkr7faFg095Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nrtzBgrnJ/98cegYCdNpDXtCrbhbPAo61BNLqhCfYQ2NV9oorcSOogo9EDiGv/eKD 94+6tFByAvXHlRfsvKSDn3It3QZXWNHpuNgrZkFEYYrRoWdrY8aDu+jTwY1tQqWiUm mdn7ik7DPSejsCv3PcgsIFOD6BTwCGxpakG5KAWfIxGE1mSOYuUiMmFB+KF/0BHAEi ECLyhm99wOcS2VGM9FSu3o7/guw/IdEugQOq3/60VtylX38CdAi1w1EGx6anqv7y8+ uU//+6jsxGxTjrIFgNVfmDKXE2tQiCeG5Vo2Q9BPnMX/FygN8gsHb1opnR19Y53PPc UN9DeP8P1s4TA== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , live-patching@vger.kernel.org, Juergen Gross Subject: [PATCH 3/4] drivers/xen/xenbus: Fix split() section placement with AutoFDO Date: Wed, 12 Nov 2025 15:47:50 -0800 Message-ID: <92a194234a0f757765e275b288bb1a7236c2c35c.1762991150.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: References: 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 compiling the kernel with -ffunction-sections enabled, the split() function gets compiled into the .text.split section. In some cases it can even be cloned into .text.split.constprop.0 or .text.split.isra.0. However, .text.split.* is already reserved for use by the Clang -fsplit-machine-functions flag, which is used by AutoFDO. That may place part of a function's code in a .text.split. section. This naming conflict causes the vmlinux linker script to wrongly place split() with other .text.split.* code, rather than where it belongs with regular text. Fix it by renaming split() to split_strings(). Cc: Juergen Gross Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit fro= m TEXT_MAIN") Signed-off-by: Josh Poimboeuf --- drivers/xen/xenbus/xenbus_xs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c index 528682bf0c7f..f794014814be 100644 --- a/drivers/xen/xenbus/xenbus_xs.c +++ b/drivers/xen/xenbus/xenbus_xs.c @@ -410,7 +410,7 @@ static char *join(const char *dir, const char *name) return (!buffer) ? ERR_PTR(-ENOMEM) : buffer; } =20 -static char **split(char *strings, unsigned int len, unsigned int *num) +static char **split_strings(char *strings, unsigned int len, unsigned int = *num) { char *p, **ret; =20 @@ -448,7 +448,7 @@ char **xenbus_directory(struct xenbus_transaction t, if (IS_ERR(strings)) return ERR_CAST(strings); =20 - return split(strings, len, num); + return split_strings(strings, len, num); } EXPORT_SYMBOL_GPL(xenbus_directory); =20 --=20 2.51.1 From nobody Tue Dec 9 02:53:47 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 799992F1FDE; Wed, 12 Nov 2025 23:48:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991280; cv=none; b=LBa9cI361gzPUoy5kvBbgU9H65HFz84QOSqJMBTcUtZdPMFzHuy6iAGCU+AHPc4gBqzP7NwJYwlDMsVSFnIPkUgqpnmRMZZJMQxaSuZ/x931DLPzr5zMYWsqQnasgx5EhfaR2WDxRtCdgqZXoy6k3xqmOOGslyf0vDbXH+rNnQo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762991280; c=relaxed/simple; bh=bLa5wT6Q9MoJLKpOwPOyb0MAjQDFxxCojERb/PzbZrc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JHqBThlI5zutxXyfEeNVh/LlQm/tkN0D8T69yPM/iUXO+ELxQJcyvzOklEoN5lBfj+Sng4A/9v0BHgz13AWeqLxNF2iLa5gDGBeUij2kqU2AMikba+j17ajh0ot/5UkNaIjRlwnosA3r/P0KTfVcO4CPOyFc2qrQUNWluREJ7xo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H20MCncK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H20MCncK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D430EC4CEF1; Wed, 12 Nov 2025 23:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762991280; bh=bLa5wT6Q9MoJLKpOwPOyb0MAjQDFxxCojERb/PzbZrc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H20MCncKA6NA1aMlT5lO0QljycPGIcbHTn/hjsYiL5WvF4HBO3bRloVNfbn8ah+QQ vmF0lSTkRHshaSBWRaYe3J6uDVEQ4YEuwx00mLSzgtN9PT7zH8lmC/w6FoTyMkNAIv yws+87UB+rhFKRNM76qkqkLsLuWCItIeDBXkbYa002rEDDU045VSbyrX89WKrIO6+a jvd+qVKwK2XVGq1YzNpimIXVhXgUPvogVW8d50+0/1qqorSR25mn/gFzYXnNJ8RlfD aqyM6FNLJEFt3JHt72zLuUBUNspslZ8FYsYb7prFdUqXWvmYlKPMmdK+1OOD76mfAJ z2deXErZ/sloA== From: Josh Poimboeuf To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , live-patching@vger.kernel.org Subject: [PATCH 4/4] objtool: Warn on functions with ambiguous -ffunction-sections section names Date: Wed, 12 Nov 2025 15:47:51 -0800 Message-ID: <65fedea974fe14be487c8867a0b8d0e4a294ce1e.1762991150.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: References: 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 compiled with -ffunction-sections, a function named startup() will be placed in .text.startup. However, .text.startup is also used by the compiler for functions with __attribute__((constructor)). That creates an ambiguity for the vmlinux linker script, which needs to differentiate those two cases. Similar naming conflicts exist for functions named exit(), split(), unlikely(), hot() and unknown(). One potential solution would be to use '#ifdef CC_USING_FUNCTION_SECTIONS' to create two distinct implementations of the TEXT_MAIN macro. However, -ffunction-sections can be (and is) enabled or disabled on a per-object basis (for example via ccflags-y or AUTOFDO_PROFILE). So the recently unified TEXT_MAIN macro (commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")) is necessary. This means there's no way for the linker script to disambiguate things. Instead, use objtool to warn on any function names whose resulting section names might create ambiguity when the kernel is compiled (in whole or in part) with -ffunction-sections. Signed-off-by: Josh Poimboeuf --- include/asm-generic/vmlinux.lds.h | 15 +++++++++++ tools/objtool/Documentation/objtool.txt | 7 ++++++ tools/objtool/check.c | 33 +++++++++++++++++++++++++ 3 files changed, 55 insertions(+) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinu= x.lds.h index 20695bc8f174..57aa01d24087 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -97,6 +97,21 @@ * Other .text.* sections that are typically grouped separately, such as * .text.unlikely or .text.hot, must be matched explicitly before using * TEXT_MAIN. + * + * NOTE: builds *with* and *without* -ffunction-sections are both supporte= d by + * this single macro. Even with -ffunction-sections, there may be some ob= jects + * NOT compiled with the flag due to the use of a specific Makefile overri= de + * like cflags-y or AUTOFDO_PROFILE_foo.o. So this single catchall rule is + * needed to support mixed object builds. + * + * One implication is that functions named startup(), exit(), split(), + * unlikely(), hot(), and unknown() are not allowed in the kernel due to t= he + * ambiguity of their section names with -ffunction-sections. For example, + * .text.startup could be __attribute__((constructor)) code in a *non* + * ffunction-sections object, which should be placed in .init.text; or it = could + * be an actual function named startup() in an ffunction-sections object, = which + * should be placed in .text. Objtool will detect and complain about any = such + * ambiguously named functions. */ #define TEXT_MAIN \ .text \ diff --git a/tools/objtool/Documentation/objtool.txt b/tools/objtool/Docume= ntation/objtool.txt index 9e97fc25b2d8..f88f8d28513a 100644 --- a/tools/objtool/Documentation/objtool.txt +++ b/tools/objtool/Documentation/objtool.txt @@ -456,6 +456,13 @@ the objtool maintainers. these special names and does not use module_init() / module_exit() macros to create them. =20 +13. file.o: warning: func() function name creates ambiguity with -ffunctio= ns-sections + + Functions named startup(), exit(), split(), unlikely(), hot(), and + unknown() are not allowed due to the ambiguity of their section + names when compiled with -ffunction-sections. For more information, + see the comment above TEXT_MAIN in include/asm-generic/vmlinux.lds.h. + =20 If the error doesn't seem to make sense, it could be a bug in objtool. Feel free to ask objtool maintainers for help. diff --git a/tools/objtool/check.c b/tools/objtool/check.c index d071fbf73e4c..ac78f6ec9758 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2662,6 +2662,37 @@ static int decode_sections(struct objtool_file *file) return 0; } =20 +/* + * Certain function names are disallowed due to section name ambiguities + * introduced by -ffunction-sections. + * + * See the comment above TEXT_MAIN in include/asm-generic/vmlinux.lds.h. + */ +static int validate_function_names(struct objtool_file *file) +{ + struct symbol *func; + int warnings =3D 0; + + for_each_sym(file->elf, func) { + if (!is_func_sym(func)) + continue; + + if (!strcmp(func->name, "startup") || strstarts(func->name, "startup.") = || + !strcmp(func->name, "exit") || strstarts(func->name, "exit.") || + !strcmp(func->name, "split") || strstarts(func->name, "split.") || + !strcmp(func->name, "unlikely") || strstarts(func->name, "unlikely."= ) || + !strcmp(func->name, "hot") || strstarts(func->name, "hot.") || + !strcmp(func->name, "unknown") || strstarts(func->name, "unknown."))= { + + WARN("%s() function name creates ambiguity with -ffunction-sections", + func->name); + warnings++; + } + } + + return warnings; +} + static bool is_special_call(struct instruction *insn) { if (insn->type =3D=3D INSN_CALL) { @@ -4928,6 +4959,8 @@ int check(struct objtool_file *file) if (!nr_insns) goto out; =20 + warnings +=3D validate_function_names(file); + if (opts.retpoline) warnings +=3D validate_retpoline(file); =20 --=20 2.51.1