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
_______________________________________________ kpatch mailing list [email protected] https://www.redhat.com/mailman/listinfo/kpatch
