From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 4CA0B32570C for ; Wed, 19 Nov 2025 08:43:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763541802; cv=none; b=bg4RrUtydXq7AeboecvsiccbGhE0MK3RfohVDs9I9hX3SdA9UcP5BaoysZQazySvlgGRZWxpqlYNA/H8Kpjsc1CCViMqY8ZNwK33VL+EuKjp5a0uMAvX7kJ3FUcO1w7mQnjD2m8bsIffGqMM2is9ipaiXhVnNxxN7tgMMPWWjLo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763541802; c=relaxed/simple; bh=umaS9H2GHgYsZveA/D7+yRDonlF9vpH802aoR7GHx3E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pRCXJWMlLQBb2hgDO5RV5ioX4lxTqk5hzjH2Z8uFvornCW+RO5znSe3jubpuXAaaemcssd/n+GUjXX+pwkMrI7PzkU1FvTRkbP/wmzdGPPfbVoD8UBtqFRg7S2WPU453ZFgpvLW/0MT8uQjRRjaeH37YkeiS8Av2z/8AlQfEOXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=KHFAurdc; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KHFAurdc" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=Gb85St2uCYPNHAzw6myg1dgLa+i7bXSHC/kqyfZ1DPs=; b=KHFAurdcnvcsN/NJQVMiSS8vx9 dESAmhCD/LGCo+QXiYLF9vEOFk+GAK00HeYnadNE2sAh3b66+FA5w0LIiwY48C8WhFemjV2TptBi/ 4wK+Oxl4U5B5Zz0L7XOLTDCNhvI/hUuETg7ypkqAJFP1pmQ/2xSg6HkWO3U5Lc0/vZiyhA0rlzMAv Pjx3UDuiFv+g4kXysnn/jeIaTAJwITHAJOgR4iH7ZAasYAlsbFEcqMFGNy/1sD4QgGZevn9w+F9Tw 7VElIL0i8p+tbm9Su+RqOasQar1uEqUNefEkUNhrDPy6BvOd1twgaxZt0clFW79rEroG8UDcU+j9s CAXij5lw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vLdmW-0000000GnAO-3lfu; Wed, 19 Nov 2025 08:43:17 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 43037300399; Wed, 19 Nov 2025 09:43:15 +0100 (CET) Date: Wed, 19 Nov 2025 09:43:15 +0100 From: Peter Zijlstra To: Jiri Slaby Cc: Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , kernel test robot Subject: Re: [PATCH] serial: icom: Fix namespace collision and startup() section placement with -ffunction-sections Message-ID: <20251119084315.GI4067720@noisy.programming.kicks-ass.net> References: <45630ac97b19b8d3194763fe7f54bb3b498f3728.1763533593.git.jpoimboe@kernel.org> <23f084ab-7b1a-485e-be1e-e639906fd5b3@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23f084ab-7b1a-485e-be1e-e639906fd5b3@kernel.org> On Wed, Nov 19, 2025 at 07:58:05AM +0100, Jiri Slaby wrote: > On 19. 11. 25, 7:27, 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. > > > > This naming conflict causes the vmlinux linker script to wrongly place > > startup() function code in .init.text, which gets freed during boot. > > This sounds rather error-prone. What are the patterns supposed to match > actually? Can't *those* real victims™ be renamed to something less common > instead? Yeah, this is a terrible mess. The problem is that when linking objects build with and without -ffunction-sections you can no longer uniquely identify what's what :-( As long as its consistently one or the other it works, but if you mix them constructors and normal function like this get mixed up. In another thread I've suggested this might be a toolchain bug, but even if they agree and fix it, we still stuck with the old compilers. And I'm not sure the toolchain people are agreeing there's anything wrong here -- the argument is that you shouldn't be mixing this or somesuch. Anyway, objtool has a warning for this, so new occurrences should be flagged before they get introduced. But yes, we need to make the tree clean first.