On Tue, Sep 11, 2018 at 12:14:30PM +0200, gregkh@linuxfoundation.org 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%3Ba=su...

...

to the 4.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

...

to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

...

to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

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-e...

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

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 stable@vger.kernel.org know about it.

From foo@baz Tue Sep 11 12:09:55 CEST 2018 From: Vasily Gorbik gor@linux.ibm.com Date: Mon, 6 Aug 2018 15:17:42 +0200 Subject: tracing: Handle CC_FLAGS_FTRACE more accurately

From: Vasily Gorbik gor@linux.ibm.com

[ 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...

Signed-off-by: Vasily Gorbik gor@linux.ibm.com Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org Signed-off-by: Sasha Levin alexander.levin@microsoft.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

---

Makefile | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/Makefile +++ b/Makefile @@ -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 gor@linux.ibm.com are

queue-4.9/tracing-handle-cc_flags_ftrace-more-accurately.patch