On Tue, Feb 16, 2021 at 09:51:21AM -0500, Steven Rostedt wrote: > On Tue, 16 Feb 2021 12:04:06 +0100 > Greg Kroah-Hartman <[email protected]> wrote: > > > Thanks for this. > > > > Should I also queue these up for 4.9 and 4.14 which do not have these > > commits in them either (but somehow do not show the problem, yet)? > > This bothers me. I want to know exactly why this is a problem.
I actually see the same problem with 4.9 and 4.14, using the same config. It's very config-specific. Something has to convince the toolchain to not reference those two weak functions by section. > That said, it is fine to backport those patches, and I would include 4.9 > and 4.14, as I would think you have a similar requirement that we have in > the stable-rt trees. That is you shouldn't experience a regression going > from an older kernel to a newer one because the older one had a fix > backported to it that a newer one did not. Basically the same rationale that > all fixes go into Linus's tree before backporting. We do the same on the > stable-rt, where all fixes go in all maintained stable trees that are newer > than the one you are backporting to. > > Although, it does allow more to be traced than what recordmcount enables. > But hopefully it doesn't cause any issues. Maybe I should do some ftrace > testing before you go and release any of those stables with those patches. > > I'm looking to see if this new "feature" of binutils isn't causing trouble > elsewhere. I'm thinking that ftrace is just the canary here. It already caused quite a bit of trouble with objtool (as did a previous similar change by the Clang assembler). -- Josh
