Michael, As part of the kpatch-build process, it needs to do a couple of temporary builds of the kernel with those flags. But the running kernel doesn't need them.
On Fri, Feb 12, 2016 at 06:38:31AM +0000, Michael Liu (zuwliu) wrote: > Hi Josh, > > the “no fentry call” error is solved after I updated the scripts/recordmcount > tool. > > I have another question though. Does the flags of "-ffunction-sections > -fdata-sections” only needed when building the patch KLM or they are required > for building the kernel? > > I see these flags are only used in the kpatch-build tool, so assume they are > NOT needed to build the kernel to be installed. Is it correct? > > Thanks > Michael > > > > > On Feb 10, 2016, at 10:04 PM, Michael Liu (zuwliu) > <[email protected]<mailto:[email protected]>> wrote: > > Hi Josh, > > I think the problem is that our scripts/recordmcount.* is not updated, that > could be the cause of __fentry__ is not there. Will update them and try it > again > > Thanks > Michael > > > > > On Feb 10, 2016, at 4:42 PM, Michael Liu (zuwliu) > <[email protected]<mailto:[email protected]>> wrote: > > Thanks Josh. > > I back ported the mfentry commits. However, the error seems more related to > the gcc. > > meminfo.o: function meminfo_proc_show has no fentry call, unable to patch > /nobackup/zuwliu/ws/kpatch/315-2/third-party/src/kpatch/kpatch-build/create-diff-object: > unreconcilable difference > > The meminfo.o is compiled with the flags of -ffunction-sections > -fdata-sections -pg -mfentry -DCC_USING_FENTRY, so wondering why the > create-diff-object tool complaints the fentry call is not found? > > > + exec i686-wrs7-linux-gnu-gcc > --sysroot=/auto/andpkg/rep_cache//wr-x86-xeon/5.0-n9k/sysroot/intel_xeon_core-wrs-linux > -Wp,-MD,fs/proc/.meminfo.o.d -nostdinc -isystem > /auto/andatc/linux/wr-x86/7.0h/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-linux/../../lib/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.1/include > > -I/nobackup/zuwliu/ws/kpatch/315-2/third-party/src/linux/kernel/wrl5-in/linux-3.4_wrl501-in/arch/x86/include > -Iarch/x86/include/generated -Iinclude > -I/nobackup/zuwliu/ws/kpatch/315-2/third-party/src/linux/kernel/wrl5-in/linux-3.4_wrl501-in/include > -include > /nobackup/zuwliu/ws/kpatch/315-2/third-party/src/linux/kernel/wrl5-in/linux-3.4_wrl501-in/include/linux/kconfig.h > > -I/nobackup/zuwliu/ws/kpatch/315-2/third-party/src/linux/kernel/wrl5-in/linux-3.4_wrl501-in/fs/proc > -Ifs/proc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs > -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration > -Wno-format-security -fno-delete-null-pointer-checks -O2 -fno-reorder-blocks > -fno-ipa-cp-clone -fno-partial-inlining -m64 -mtune=generic -mno-red-zone > -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 > -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 > -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables > -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048 > -fno-stack-protector -Wno-unused-but-set-variable -fno-omit-frame-pointer > -fno-optimize-sibling-calls -g -pg -Wdeclaration-after-statement > -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO > -I/nobackup/zuwliu/ws/kpatch/315-2/third-party/src/kpatch/kmod/patch > -ffunction-sections -fdata-sections -pg -mfentry -DCC_USING_FENTRY > '-DKBUILD_STR(s)=#s' '-DKBUILD_BASENAME=KBUILD_STR(meminfo)' > '-DKBUILD_MODNAME=KBUILD_STR(proc)' -c -o fs/proc/meminfo.o > /nobackup/zuwliu/ws/kpatch/315-2/third-party/src/linux/kernel/wrl5-in/linux-3.4_wrl501-in/fs/proc/meminfo.c > > [zuwliu@sjc-ads-5151 final.x86e-3.4]$ i686-wrs7-linux-gnu-gcc --version > i686-wrs7-linux-gnu-gcc (Wind River Linux 4.9.1-7.0-intel-x86-64) 4.9.1 > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Thanks > Michael > > > > > On Feb 9, 2016, at 7:34 PM, Josh Poimboeuf > <[email protected]<mailto:[email protected]>> wrote: > > Michael, > > fentry is required (and mcount won't work). > > On Wed, Feb 10, 2016 at 01:42:37AM +0000, Michael Liu (zuwliu) wrote: > Hi Josh, > > When I run kpatch-build tool for the memnfo-string.patch on our 3.4 kernel, I > got an error of > > meminfo.o: function meminfo_proc_show has no fentry call, unable to patch > > It seems the fentry support is added in > d57c5d51a30152f3175d2344cb6395f08bf8ee0c, which I didn’t backport yet. Should > I backport it and maybe some other commits? > > Or there is a kpatch version which only use mcount instead of fentry? > > > commit d57c5d51a30152f3175d2344cb6395f08bf8ee0c > Author: Steven Rostedt > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > Date: Wed Feb 9 13:32:18 2011 -0500 > > ftrace/x86: Add support for -mfentry to x86_64 > > > > Thanks > Michael > > > > > On Jan 27, 2016, at 7:55 PM, Josh Poimboeuf > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > wrote: > > Michael, > > The 06aeaaeabf69da4a3e86df532425640f51b01cef commit seems to be just a > cosmetic change so I don't think you need it (unless it's a dependency > for another needed change). > > Otherwise I'm not sure what else you need. > > On Wed, Jan 27, 2016 at 04:16:39AM +0000, Michael Liu (zuwliu) wrote: > Hi Josh, > > Wondering to which stage of ftrace I need to backport to 3.4 kernel? I > already back ported commits: > > 08f6fba503111e0336f2b4d6915a4a18f9b60e51 (ftrace/x86: Add separate function > to save regs) > 647664eaf4033501739ac1f42dd52ce8c9266ccc (ftrace: add ftrace_set_filter_ip() > for address based filter) > > Now I can compile kmod/core KLM in kpatch on 3.4 kernel. Wondering do I need > also backport the commit of > > 06aeaaeabf69da4a3e86df532425640f51b01cef (ftrace: Move > ARCH_SUPPORTS_FTRACE_SAVE_REGS in Kconfig) > > to make kpatch really work on 3.4 kernel? > > Really appreciate your help! > > Thanks > Michael > > > > > On Jan 20, 2016, at 7:39 AM, Josh Poimboeuf > <[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]>> > wrote: > > On Tue, Jan 19, 2016 at 04:15:10PM +0000, Michael Liu (zuwliu) wrote: > I joined the member and try to send it again. > > Hello Kpatch, > > I’m in a project which requires running kpatch on our 3.4 kernel, wondering > how much effort is needed to do so? > > We currently using GCC 4.6.3, but I think we can move to GCC 4.8 if needed. > However we cannot move our kernel to 3.9. > > In 3.4 kernel I saw there is already ftrace, although there is no > CONFIG_DYNAMIC_FTRACE_WITH_REGS feature. Wondering whether > CONFIG_DYNAMIC_FTRACE_WITH_REGS is the only feature missing on 3.4 to support > kpatch? Are there other things we need to backport to run kpatch on 3.4 > kernel? > > Thank you for your time! > > Hi Michael, > > CONFIG_DYNAMIC_FTRACE_WITH_REGS is the biggest required feature I know > about that's missing on 3.4. > > Also, there are at least some minor kernel API differences that affect > the kpatch core module, described here: > > https://github.com/dynup/kpatch/issues/257 > > GCC 4.6 may have issues: > > https://github.com/dynup/kpatch/issues/246#issuecomment-46615292 > > Those are just the problems I know about. You might run into other > issues... > > -- > Josh > > > -- > Josh > > > -- > Josh > > > -- Josh _______________________________________________ kpatch mailing list [email protected] https://www.redhat.com/mailman/listinfo/kpatch
