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 <hansg@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 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/staging/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 on)
 }
 
 /* TODO: remove it. */
-static int startup(struct v4l2_subdev *sd)
+static int ov2722_startup(struct v4l2_subdev *sd)
 {
 	struct ov2722_device *dev = to_ov2722_sensor(sd);
 	struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -662,7 +662,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd,
 	dev->pixels_per_line = dev->res->pixels_per_line;
 	dev->lines_per_frame = dev->res->lines_per_frame;
 
-	ret = startup(sd);
+	ret = ov2722_startup(sd);
 	if (ret) {
 		int i = 0;
 
@@ -677,7 +677,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd,
 				dev_err(&client->dev, "power up failed, continue\n");
 				continue;
 			}
-			ret = startup(sd);
+			ret = ov2722_startup(sd);
 			if (ret) {
 				dev_err(&client->dev, " startup FAILED!\n");
 			} else {
-- 
2.51.1

On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> 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.
> 

Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
the compiler should never put regular non-reserved user symbols in a
section it has reserved for itself, right?

On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> > 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.
> > 
> 
> Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> the compiler should never put regular non-reserved user symbols in a
> section it has reserved for itself, right?

Right, so there's no ambiguity *IF* we know in advance whether it was
compiled with -ffunction-sections.  If so, constructor code goes in
.text.startup.*, and startup() goes in .text.startup or
.text.startup.constprop.0 or .text.startup.isra.0.

So it's not really a compiler bug because it's possible to disambiguate
those.

Problem is, we can have some objects compiled with -ffunction-sections,
and some compiled without, in the same kernel.  So the disambiguation
isn't possible at link time, since for example .text.startup could be
startup() with -ffunction-sections, or it could be
__attribute__((constructor)) without -ffunction-sections.

I attempted to describe all that in patch 4.

-- 
Josh

On Fri, Nov 14, 2025 at 12:43:10PM -0800, Josh Poimboeuf wrote:
> On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> > > 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.
> > > 
> > 
> > Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> > the compiler should never put regular non-reserved user symbols in a
> > section it has reserved for itself, right?
> 
> Right, so there's no ambiguity *IF* we know in advance whether it was
> compiled with -ffunction-sections.  If so, constructor code goes in
> .text.startup.*, and startup() goes in .text.startup or
> .text.startup.constprop.0 or .text.startup.isra.0.
> 
> So it's not really a compiler bug because it's possible to disambiguate
> those.
> 
> Problem is, we can have some objects compiled with -ffunction-sections,
> and some compiled without, in the same kernel.  So the disambiguation
> isn't possible at link time, since for example .text.startup could be
> startup() with -ffunction-sections, or it could be
> __attribute__((constructor)) without -ffunction-sections.
> 
> I attempted to describe all that in patch 4.

Egads, what a mess :-(