Patch "tracing: Handle CC_FLAGS_FTRACE more accurately" has been added to the ...-stable tree

DISCUSSION Vasily Gorbik 2 participants 2 messages Sep 12, 2018 3 messages not in the archive Stable branch

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Vasily Gorbik

author

2018-09-12 20:41 UTC #1 lore raw

Quoted 7 lines · On Tue, Sep 11, 2018 at 12:14:30PM +0200, [email protected] wrote:

This is a note to let you know that I've just added the patch titled
tracing: Handle CC_FLAGS_FTRACE more accurately
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

...

Quoted 2 lines

to the 4.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

...

Quoted 2 lines

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

...

Quoted 3 lines

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

I believe there is no need to backport this patch in neither of stable branches listed above. This patch is the first one in the patch series:
http://lkml.kernel.org/r/cover.thread-aa7b8d.your-ad-here.call-01533557518-ext-9465@work.hours

The patch series adds s390 support for utilizing newly available for s390 in gcc 9 flags -fentry -mrecord-mcount and -mnop-mcount, and adds generic -mnop-mcount support. And there is no benefit in backporting just the first one.

Moreover this patch cause kernel recompile for intdeb-pkg and tar%pkg targets (i.e. make targz-pkg), because those targets call make recursively (they do extra "make modules_install"), and exported variable cause duplicated build flags in sub-make.

There is a potential fix:
https://www.spinics.net/lists/linux-kbuild/msg19297.html

Quoted 68 lines

The filename of the patch is:
tracing-handle-cc_flags_ftrace-more-accurately.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
From foo@baz Tue Sep 11 12:09:55 CEST 2018
From: Vasily Gorbik <[email protected]>
Date: Mon, 6 Aug 2018 15:17:42 +0200
Subject: tracing: Handle CC_FLAGS_FTRACE more accurately
From: Vasily Gorbik <[email protected]>
[ Upstream commit f28bc3c32c059ab4d13f52155fabd3e20f477f65 ]
CC_FLAGS_FTRACE is exported and later used to remove ftrace relevant build flags from files which should be built without ftrace support. For that reason add -mfentry to CC_FLAGS_FTRACE as well. That fixes a problem with vdso32 build on s390, where -mfentry could not be used together with -m31 flag.
At the same time flags like -pg and -mfentry are not relevant for asm files, so avoid adding them to KBUILD_AFLAGS.
Introduce CC_FLAGS_USING instead of CC_USING_FENTRY to collect -DCC_USING_FENTRY (and future alike) which are relevant for both KBUILD_CFLAGS and KBUILD_AFLAGS.
Link http://lkml.kernel.org/r/patch-1.thread-aa7b8d.git-42971afe87de.your-ad-here.call-01533557518-ext-9465@work.hours open here
Signed-off-by Vasily Gorbik <[email protected]>
Signed-off-by Steven Rostedt (VMware) <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 Makefile |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
Makefile +7 -4
@@ -760,12 +760,15 @@ ifdef CONFIG_FUNCTION_TRACER
 ifndef CC_FLAGS_FTRACE
 CC_FLAGS_FTRACE := -pg
 endif
-export CC_FLAGS_FTRACE
 ifdef CONFIG_HAVE_FENTRY
-CC_USING_FENTRY	:= $(call cc-option, -mfentry -DCC_USING_FENTRY)
+  ifeq ($(call cc-option-yn, -mfentry),y)
+    CC_FLAGS_FTRACE	+= -mfentry
+    CC_FLAGS_USING	+= -DCC_USING_FENTRY
+  endif
 endif
-KBUILD_CFLAGS	+= $(CC_FLAGS_FTRACE) $(CC_USING_FENTRY)
-KBUILD_AFLAGS	+= $(CC_USING_FENTRY)
+export CC_FLAGS_FTRACE
+KBUILD_CFLAGS	+= $(CC_FLAGS_FTRACE) $(CC_FLAGS_USING)
+KBUILD_AFLAGS	+= $(CC_FLAGS_USING)
 ifdef CONFIG_DYNAMIC_FTRACE
 	ifdef CONFIG_HAVE_C_RECORDMCOUNT
 		BUILD_C_RECORDMCOUNT := y
Patches currently in stable-queue which might be from [email protected] are
queue-4.9/tracing-handle-cc_flags_ftrace-more-accurately.patch

Greg KH

maintainer

2018-09-12 23:30 UTC #2 lore raw

Quoted 34 lines · Vasily Gorbik

Quoted 7 lines · On Tue, Sep 11, 2018 at 12:14:30PM +0200, [email protected] wrote:
This is a note to let you know that I've just added the patch titled
tracing: Handle CC_FLAGS_FTRACE more accurately
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
...
Quoted 2 lines
to the 4.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
...
Quoted 2 lines
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
...
Quoted 3 lines
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
I believe there is no need to backport this patch in neither of stable branches listed above. This patch is the first one in the patch series:
http://lkml.kernel.org/r/cover.thread-aa7b8d.your-ad-here.call-01533557518-ext-9465@work.hours
The patch series adds s390 support for utilizing newly available for s390 in gcc 9 flags -fentry -mrecord-mcount and -mnop-mcount, and adds generic -mnop-mcount support. And there is no benefit in backporting just the first one.

Quoted 7 lines

Moreover this patch cause kernel recompile for intdeb-pkg and tar%pkg targets (i.e. make targz-pkg), because those targets call make recursively (they do extra "make modules_install"), and exported variable cause duplicated build flags in sub-make.
There is a potential fix:
https://www.spinics.net/lists/linux-kbuild/msg19297.html

Thanks for letting me know, I've dropped this from everywhere now.

greg k-h