Message ID | 20220912082020.226755-12-sv@linux.ibm.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers | show |
Series | objtool: Enable and implement --mcount option on powerpc | expand |
Hi Sathvika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/topic/ppc-kvm]
[also build test ERROR on linus/master v6.0-rc5]
[cannot apply to powerpc/next masahiroy-kbuild/for-next next-20220912]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220913/202209130240.GpGMxW7T-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/ca5e2b42c0d4438ba93623579b6860b98f3598f3
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
git checkout ca5e2b42c0d4438ba93623579b6860b98f3598f3
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> cc1: error: '-mnop-mcount' is not implemented for '-fPIC'
kernel test robot wrote: > Hi Sathvika, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on powerpc/topic/ppc-kvm] > [also build test ERROR on linus/master v6.0-rc5] > [cannot apply to powerpc/next masahiroy-kbuild/for-next next-20220912] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm > config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220913/202209130240.GpGMxW7T-lkp@intel.com/config) > compiler: gcc-11 (Debian 11.3.0-5) 11.3.0 > reproduce (this is a W=1 build): > # https://github.com/intel-lab-lkp/linux/commit/ca5e2b42c0d4438ba93623579b6860b98f3598f3 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 > git checkout ca5e2b42c0d4438ba93623579b6860b98f3598f3 > # save the config file > mkdir build_dir && cp config build_dir/.config > make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash > > If you fix the issue, kindly add following tag where applicable > Reported-by: kernel test robot <lkp@intel.com> Thanks. > > All errors (new ones prefixed by >>): > >>> cc1: error: '-mnop-mcount' is not implemented for '-fPIC' CONFIG_NOP_MCOUNT is used for FTRACE_MCOUNT_USE_CC, so instead of: diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f9920f1341c8..a8dd138df637 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -189,6 +189,7 @@ config X86 select HAVE_CONTEXT_TRACKING_USER_OFFSTACK if HAVE_CONTEXT_TRACKING_USER select HAVE_C_RECORDMCOUNT select HAVE_OBJTOOL_MCOUNT if HAVE_OBJTOOL + select HAVE_NOP_MCOUNT if HAVE_OBJTOOL_MCOUNT select HAVE_BUILDTIME_MCOUNT_SORT select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_CONTIGUOUS I think you should do: + select HAVE_NOP_MCOUNT if FTRACE_MCOUNT_USE_OBJTOOL I was hoping we could reuse CONFIG_NOP_MCOUNT seeing as it is only used by s390, but I now wonder if it is better to just keep that separate. We could introduce HAVE_OBJTOOL_NOP_MCOUNT for objtool instead. - Naveen
Hi Sathvika, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/topic/ppc-kvm] [also build test WARNING on linus/master v6.0-rc5] [cannot apply to powerpc/next masahiroy-kbuild/for-next next-20220916] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm config: x86_64-randconfig-m001 (https://download.01.org/0day-ci/archive/20220918/202209180354.tm3Z4uPD-lkp@intel.com/config) compiler: gcc-11 (Debian 11.3.0-5) 11.3.0 reproduce (this is a W=1 build): # https://github.com/intel-lab-lkp/linux/commit/ca5e2b42c0d4438ba93623579b6860b98f3598f3 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 git checkout ca5e2b42c0d4438ba93623579b6860b98f3598f3 # save the config file mkdir build_dir && cp config build_dir/.config make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot <lkp@intel.com> All warnings (new ones prefixed by >>): >> vmlinux.o: warning: objtool: exc_page_fault+0xe: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: get_cpu_entry_area+0x3: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: __stack_chk_fail+0x0: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section >> vmlinux.o: warning: objtool: __ktime_get_real_seconds+0x0: call to __sanitizer_cov_trace_pc() leaves .noinstr.text section objdump-func vmlinux.o exc_page_fault: 0000 00000000000020c0 <exc_page_fault>: 0000 20c0: 41 56 push %r14 0002 20c2: 41 55 push %r13 0004 20c4: 49 89 f5 mov %rsi,%r13 0007 20c7: 41 54 push %r12 0009 20c9: 55 push %rbp 000a 20ca: 48 89 fd mov %rdi,%rbp 000d 20cd: 53 push %rbx 000e 20ce: e8 00 00 00 00 call 20d3 <exc_page_fault+0x13> 20cf: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0013 20d3: 41 0f 20 d4 mov %cr2,%r12 0017 20d7: 48 8b 04 25 00 00 00 00 mov 0x0,%rax 20db: R_X86_64_32S current_task 001f 20df: 48 8b 80 b8 03 00 00 mov 0x3b8(%rax),%rax 0026 20e6: 0f 18 88 b0 00 00 00 prefetcht0 0xb0(%rax) 002d 20ed: 44 8b 35 00 00 00 00 mov 0x0(%rip),%r14d # 20f4 <exc_page_fault+0x34> 20f0: R_X86_64_PC32 kvm_async_pf_enabled-0x4 0034 20f4: 31 ff xor %edi,%edi 0036 20f6: 44 89 f6 mov %r14d,%esi 0039 20f9: e8 00 00 00 00 call 20fe <exc_page_fault+0x3e> 20fa: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 003e 20fe: 45 85 f6 test %r14d,%r14d 0041 2101: 0f 8f c9 00 00 00 jg 21d0 <exc_page_fault+0x110> 0047 2107: e8 00 00 00 00 call 210c <exc_page_fault+0x4c> 2108: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 004c 210c: 48 89 ef mov %rbp,%rdi 004f 210f: e8 00 00 00 00 call 2114 <exc_page_fault+0x54> 2110: R_X86_64_PLT32 irqentry_enter-0x4 0054 2114: 41 89 c6 mov %eax,%r14d 0057 2117: 90 nop 0058 2118: 8b 1d 00 00 00 00 mov 0x0(%rip),%ebx # 211e <exc_page_fault+0x5e> 211a: R_X86_64_PC32 trace_pagefault_key-0x4 005e 211e: 31 ff xor %edi,%edi 0060 2120: 89 de mov %ebx,%esi 0062 2122: e8 00 00 00 00 call 2127 <exc_page_fault+0x67> 2123: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 0067 2127: 85 db test %ebx,%ebx 0069 2129: 0f 8f c6 00 00 00 jg 21f5 <exc_page_fault+0x135> 006f 212f: e8 00 00 00 00 call 2134 <exc_page_fault+0x74> 2130: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0074 2134: 4c 89 e3 mov %r12,%rbx 0077 2137: 48 c7 c7 00 00 60 ff mov $0xffffffffff600000,%rdi 007e 213e: 48 81 e3 00 f0 ff ff and $0xfffffffffffff000,%rbx 0085 2145: 48 89 de mov %rbx,%rsi 0088 2148: e8 00 00 00 00 call 214d <exc_page_fault+0x8d> 2149: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp8-0x4 008d 214d: 48 81 fb 00 00 60 ff cmp $0xffffffffff600000,%rbx 0094 2154: 74 23 je 2179 <exc_page_fault+0xb9> 0096 2156: 48 bb ff ef ff ff ff 7f 00 00 movabs $0x7fffffffefff,%rbx 00a0 2160: e8 00 00 00 00 call 2165 <exc_page_fault+0xa5> 2161: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 00a5 2165: 4c 89 e6 mov %r12,%rsi 00a8 2168: 48 89 df mov %rbx,%rdi 00ab 216b: e8 00 00 00 00 call 2170 <exc_page_fault+0xb0> 216c: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp8-0x4 00b0 2170: 49 39 dc cmp %rbx,%r12 00b3 2173: 0f 87 47 01 00 00 ja 22c0 <exc_page_fault+0x200> 00b9 2179: e8 00 00 00 00 call 217e <exc_page_fault+0xbe> 217a: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 00be 217e: 4c 89 e2 mov %r12,%rdx 00c1 2181: 4c 89 ee mov %r13,%rsi 00c4 2184: 48 89 ef mov %rbp,%rdi 00c7 2187: e8 00 00 00 00 call 218c <exc_page_fault+0xcc> 2188: R_X86_64_PC32 .text+0x6fcfc 00cc 218c: 9c pushf 00cd 218d: 41 5c pop %r12 00cf 218f: 41 81 e4 00 02 00 00 and $0x200,%r12d 00d6 2196: fa cli 00d7 2197: 31 ff xor %edi,%edi 00d9 2199: 4c 89 e6 mov %r12,%rsi 00dc 219c: e8 00 00 00 00 call 21a1 <exc_page_fault+0xe1> 219d: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp8-0x4 00e1 21a1: 4d 85 e4 test %r12,%r12 00e4 21a4: 75 1e jne 21c4 <exc_page_fault+0x104> 00e6 21a6: e8 00 00 00 00 call 21ab <exc_page_fault+0xeb> 21a7: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 00eb 21ab: 90 nop 00ec 21ac: 44 89 f6 mov %r14d,%esi 00ef 21af: 48 89 ef mov %rbp,%rdi 00f2 21b2: e8 00 00 00 00 call 21b7 <exc_page_fault+0xf7> 21b3: R_X86_64_PLT32 irqentry_exit-0x4 00f7 21b7: 5b pop %rbx 00f8 21b8: 5d pop %rbp 00f9 21b9: 41 5c pop %r12 00fb 21bb: 41 5d pop %r13 00fd 21bd: 41 5e pop %r14 00ff 21bf: e9 00 00 00 00 jmp 21c4 <exc_page_fault+0x104> 21c0: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0104 21c4: e8 00 00 00 00 call 21c9 <exc_page_fault+0x109> 21c5: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0109 21c9: e8 00 00 00 00 call 21ce <exc_page_fault+0x10e> 21ca: R_X86_64_PLT32 trace_hardirqs_off-0x4 010e 21ce: eb d6 jmp 21a6 <exc_page_fault+0xe6> 0110 21d0: e8 00 00 00 00 call 21d5 <exc_page_fault+0x115> 21d1: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0115 21d5: 44 89 e6 mov %r12d,%esi 0118 21d8: 48 89 ef mov %rbp,%rdi 011b 21db: e8 00 00 00 00 call 21e0 <exc_page_fault+0x120> 21dc: R_X86_64_PLT32 __kvm_handle_async_pf-0x4 0120 21e0: 31 ff xor %edi,%edi 0122 21e2: 89 c3 mov %eax,%ebx 0124 21e4: 89 c6 mov %eax,%esi 0126 21e6: e8 00 00 00 00 call 21eb <exc_page_fault+0x12b> 21e7: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp1-0x4 012b 21eb: 84 db test %bl,%bl 012d 21ed: 0f 84 14 ff ff ff je 2107 <exc_page_fault+0x47> 0133 21f3: eb c2 jmp 21b7 <exc_page_fault+0xf7> 0135 21f5: e8 00 00 00 00 call 21fa <exc_page_fault+0x13a> 21f6: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 013a 21fa: 48 8b 9d 88 00 00 00 mov 0x88(%rbp),%rbx 0141 2201: 31 ff xor %edi,%edi 0143 2203: 83 e3 03 and $0x3,%ebx 0146 2206: 48 89 de mov %rbx,%rsi 0149 2209: e8 00 00 00 00 call 220e <exc_page_fault+0x14e> 220a: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp8-0x4 014e 220e: 48 85 db test %rbx,%rbx 0151 2211: 0f 84 02 01 00 00 je 2319 <exc_page_fault+0x259> 0157 2217: e8 00 00 00 00 call 221c <exc_page_fault+0x15c> 2218: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 015c 221c: 8b 1d 00 00 00 00 mov 0x0(%rip),%ebx # 2222 <exc_page_fault+0x162> 221e: R_X86_64_PC32 __tracepoint_page_fault_user+0x4 0162 2222: 31 ff xor %edi,%edi 0164 2224: 89 de mov %ebx,%esi 0166 2226: e8 00 00 00 00 call 222b <exc_page_fault+0x16b> 2227: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 016b 222b: 85 db test %ebx,%ebx 016d 222d: 0f 8f dc 01 00 00 jg 240f <exc_page_fault+0x34f> 0173 2233: e8 00 00 00 00 call 2238 <exc_page_fault+0x178> 2234: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0178 2238: ff 05 00 00 00 00 incl 0x0(%rip) # 223e <exc_page_fault+0x17e> 223a: R_X86_64_PC32 __preempt_count-0x4 017e 223e: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2245 <exc_page_fault+0x185> 2241: R_X86_64_PC32 __tracepoint_page_fault_user+0x34 0185 2245: e8 00 00 00 00 call 224a <exc_page_fault+0x18a> 2246: R_X86_64_PLT32 rcu_read_lock_sched_held-0x4 018a 224a: 31 ff xor %edi,%edi 018c 224c: 89 c3 mov %eax,%ebx 018e 224e: 89 c6 mov %eax,%esi 0190 2250: e8 00 00 00 00 call 2255 <exc_page_fault+0x195> 2251: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 0195 2255: 85 db test %ebx,%ebx 0197 2257: 0f 85 fe 00 00 00 jne 235b <exc_page_fault+0x29b> 019d 225d: e8 00 00 00 00 call 2262 <exc_page_fault+0x1a2> 225e: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 01a2 2262: e8 00 00 00 00 call 2267 <exc_page_fault+0x1a7> 2263: R_X86_64_PLT32 debug_lockdep_rcu_enabled-0x4 01a7 2267: 31 ff xor %edi,%edi 01a9 2269: 89 c3 mov %eax,%ebx 01ab 226b: 89 c6 mov %eax,%esi 01ad 226d: e8 00 00 00 00 call 2272 <exc_page_fault+0x1b2> 226e: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 01b2 2272: 85 db test %ebx,%ebx 01b4 2274: 0f 84 e1 00 00 00 je 235b <exc_page_fault+0x29b> 01ba 227a: e8 00 00 00 00 call 227f <exc_page_fault+0x1bf> 227b: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 01bf 227f: 0f b6 1d 00 00 00 00 movzbl 0x0(%rip),%ebx # 2286 <exc_page_fault+0x1c6> 2282: R_X86_64_PC32 .data.unlikely+0x23 01c6 2286: 31 ff xor %edi,%edi 01c8 2288: 89 de mov %ebx,%esi 01ca 228a: e8 00 00 00 00 call 228f <exc_page_fault+0x1cf> 228b: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp1-0x4 01cf 228f: 84 db test %bl,%bl 01d1 2291: 0f 85 c4 00 00 00 jne 235b <exc_page_fault+0x29b> 01d7 2297: e8 00 00 00 00 call 229c <exc_page_fault+0x1dc> 2298: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 01dc 229c: 48 c7 c2 00 00 00 00 mov $0x0,%rdx 229f: R_X86_64_32S .rodata.str1.8+0xafd8 01e3 22a3: be 2c 00 00 00 mov $0x2c,%esi 01e8 22a8: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 22ab: R_X86_64_32S .rodata.str1.8+0xb008 01ef 22af: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # 22b6 <exc_page_fault+0x1f6> 22b1: R_X86_64_PC32 .data.unlikely+0x22 01f6 22b6: e8 00 00 00 00 call 22bb <exc_page_fault+0x1fb> 22b7: R_X86_64_PLT32 lockdep_rcu_suspicious-0x4 01fb 22bb: e9 9b 00 00 00 jmp 235b <exc_page_fault+0x29b> 0200 22c0: e8 00 00 00 00 call 22c5 <exc_page_fault+0x205> 22c1: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0205 22c5: 4c 89 eb mov %r13,%rbx 0208 22c8: 31 ff xor %edi,%edi 020a 22ca: 83 e3 20 and $0x20,%ebx 020d 22cd: 48 89 de mov %rbx,%rsi 0210 22d0: e8 00 00 00 00 call 22d5 <exc_page_fault+0x215> 22d1: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp8-0x4 0215 22d5: 48 85 db test %rbx,%rbx 0218 22d8: 0f 85 e5 00 00 00 jne 23c3 <exc_page_fault+0x303> 021e 22de: e8 00 00 00 00 call 22e3 <exc_page_fault+0x223> 22df: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0223 22e3: 4c 89 e6 mov %r12,%rsi 0226 22e6: 4c 89 ef mov %r13,%rdi 0229 22e9: e8 00 00 00 00 call 22ee <exc_page_fault+0x22e> 22ea: R_X86_64_PC32 .text+0x706fc 022e 22ee: 31 ff xor %edi,%edi 0230 22f0: 89 c3 mov %eax,%ebx 0232 22f2: 89 c6 mov %eax,%esi 0234 22f4: e8 00 00 00 00 call 22f9 <exc_page_fault+0x239> 22f5: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 0239 22f9: 85 db test %ebx,%ebx 023b 22fb: 0f 85 a5 fe ff ff jne 21a6 <exc_page_fault+0xe6> 0241 2301: e8 00 00 00 00 call 2306 <exc_page_fault+0x246> 2302: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0246 2306: 4c 89 e2 mov %r12,%rdx 0249 2309: 4c 89 ee mov %r13,%rsi 024c 230c: 48 89 ef mov %rbp,%rdi 024f 230f: e8 00 00 00 00 call 2314 <exc_page_fault+0x254> 2310: R_X86_64_PC32 .text+0x6fbbc 0254 2314: e9 8d fe ff ff jmp 21a6 <exc_page_fault+0xe6> 0259 2319: e8 00 00 00 00 call 231e <exc_page_fault+0x25e> 231a: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 025e 231e: 8b 1d 00 00 00 00 mov 0x0(%rip),%ebx # 2324 <exc_page_fault+0x264> 2320: R_X86_64_PC32 __tracepoint_page_fault_kernel+0x4 0264 2324: 31 ff xor %edi,%edi 0266 2326: 89 de mov %ebx,%esi 0268 2328: e8 00 00 00 00 call 232d <exc_page_fault+0x26d> 2329: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 026d 232d: 85 db test %ebx,%ebx 026f 232f: 0f 8f 9c 00 00 00 jg 23d1 <exc_page_fault+0x311> 0275 2335: e8 00 00 00 00 call 233a <exc_page_fault+0x27a> 2336: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 027a 233a: ff 05 00 00 00 00 incl 0x0(%rip) # 2340 <exc_page_fault+0x280> 233c: R_X86_64_PC32 __preempt_count-0x4 0280 2340: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2347 <exc_page_fault+0x287> 2343: R_X86_64_PC32 __tracepoint_page_fault_kernel+0x34 0287 2347: e8 00 00 00 00 call 234c <exc_page_fault+0x28c> 2348: R_X86_64_PLT32 rcu_read_lock_sched_held-0x4 028c 234c: 31 ff xor %edi,%edi 028e 234e: 89 c3 mov %eax,%ebx 0290 2350: 89 c6 mov %eax,%esi 0292 2352: e8 00 00 00 00 call 2357 <exc_page_fault+0x297> 2353: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 0297 2357: 85 db test %ebx,%ebx 0299 2359: 74 10 je 236b <exc_page_fault+0x2ab> 029b 235b: e8 00 00 00 00 call 2360 <exc_page_fault+0x2a0> 235c: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 02a0 2360: ff 0d 00 00 00 00 decl 0x0(%rip) # 2366 <exc_page_fault+0x2a6> 2362: R_X86_64_PC32 __preempt_count-0x4 02a6 2366: e9 c4 fd ff ff jmp 212f <exc_page_fault+0x6f> 02ab 236b: e8 00 00 00 00 call 2370 <exc_page_fault+0x2b0> 236c: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 02b0 2370: e8 00 00 00 00 call 2375 <exc_page_fault+0x2b5> 2371: R_X86_64_PLT32 debug_lockdep_rcu_enabled-0x4 02b5 2375: 31 ff xor %edi,%edi 02b7 2377: 89 c3 mov %eax,%ebx 02b9 2379: 89 c6 mov %eax,%esi 02bb 237b: e8 00 00 00 00 call 2380 <exc_page_fault+0x2c0> 237c: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp4-0x4 02c0 2380: 85 db test %ebx,%ebx 02c2 2382: 74 d7 je 235b <exc_page_fault+0x29b> 02c4 2384: e8 00 00 00 00 call 2389 <exc_page_fault+0x2c9> 2385: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 02c9 2389: 0f b6 1d 00 00 00 00 movzbl 0x0(%rip),%ebx # 2390 <exc_page_fault+0x2d0> 238c: R_X86_64_PC32 .data.unlikely+0x22 02d0 2390: 31 ff xor %edi,%edi 02d2 2392: 89 de mov %ebx,%esi 02d4 2394: e8 00 00 00 00 call 2399 <exc_page_fault+0x2d9> 2395: R_X86_64_PLT32 __sanitizer_cov_trace_const_cmp1-0x4 02d9 2399: 84 db test %bl,%bl 02db 239b: 75 be jne 235b <exc_page_fault+0x29b> 02dd 239d: e8 00 00 00 00 call 23a2 <exc_page_fault+0x2e2> 239e: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 02e2 23a2: 48 c7 c2 00 00 00 00 mov $0x0,%rdx 23a5: R_X86_64_32S .rodata.str1.8+0xafd8 02e9 23a9: be 2d 00 00 00 mov $0x2d,%esi 02ee 23ae: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 23b1: R_X86_64_32S .rodata.str1.8+0xb008 02f5 23b5: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # 23bc <exc_page_fault+0x2fc> 23b7: R_X86_64_PC32 .data.unlikely+0x21 02fc 23bc: e8 00 00 00 00 call 23c1 <exc_page_fault+0x301> 23bd: R_X86_64_PLT32 lockdep_rcu_suspicious-0x4 0301 23c1: eb 98 jmp 235b <exc_page_fault+0x29b> 0303 23c3: e8 00 00 00 00 call 23c8 <exc_page_fault+0x308> 23c4: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0308 23c8: 90 nop 0309 23c9: 0f 0b ud2 030b 23cb: 90 nop 030c 23cc: e9 0d ff ff ff jmp 22de <exc_page_fault+0x21e> 0311 23d1: e8 00 00 00 00 call 23d6 <exc_page_fault+0x316> 23d2: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0316 23d6: ff 05 00 00 00 00 incl 0x0(%rip) # 23dc <exc_page_fault+0x31c> 23d8: R_X86_64_PC32 __preempt_count-0x4 031c 23dc: 48 8b 1d 00 00 00 00 mov 0x0(%rip),%rbx # 23e3 <exc_page_fault+0x323> 23df: R_X86_64_PC32 __tracepoint_page_fault_kernel+0x34 0323 23e3: 48 85 db test %rbx,%rbx 0326 23e6: 74 17 je 23ff <exc_page_fault+0x33f> 0328 23e8: e8 00 00 00 00 call 23ed <exc_page_fault+0x32d> 23e9: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 032d 23ed: 48 8b 7b 08 mov 0x8(%rbx),%rdi 0331 23f1: 4c 89 e9 mov %r13,%rcx 0334 23f4: 48 89 ea mov %rbp,%rdx 0337 23f7: 4c 89 e6 mov %r12,%rsi 033a 23fa: e8 00 00 00 00 call 23ff <exc_page_fault+0x33f> 23fb: R_X86_64_PLT32 __SCT__tp_func_page_fault_kernel-0x4 033f 23ff: e8 00 00 00 00 call 2404 <exc_page_fault+0x344> 2400: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0344 2404: ff 0d 00 00 00 00 decl 0x0(%rip) # 240a <exc_page_fault+0x34a> 2406: R_X86_64_PC32 __preempt_count-0x4 034a 240a: e9 26 ff ff ff jmp 2335 <exc_page_fault+0x275> 034f 240f: e8 00 00 00 00 call 2414 <exc_page_fault+0x354> 2410: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0354 2414: ff 05 00 00 00 00 incl 0x0(%rip) # 241a <exc_page_fault+0x35a> 2416: R_X86_64_PC32 __preempt_count-0x4 035a 241a: 48 8b 1d 00 00 00 00 mov 0x0(%rip),%rbx # 2421 <exc_page_fault+0x361> 241d: R_X86_64_PC32 __tracepoint_page_fault_user+0x34 0361 2421: 48 85 db test %rbx,%rbx 0364 2424: 74 17 je 243d <exc_page_fault+0x37d> 0366 2426: e8 00 00 00 00 call 242b <exc_page_fault+0x36b> 2427: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 036b 242b: 48 8b 7b 08 mov 0x8(%rbx),%rdi 036f 242f: 4c 89 e9 mov %r13,%rcx 0372 2432: 48 89 ea mov %rbp,%rdx 0375 2435: 4c 89 e6 mov %r12,%rsi 0378 2438: e8 00 00 00 00 call 243d <exc_page_fault+0x37d> 2439: R_X86_64_PLT32 __SCT__tp_func_page_fault_user-0x4 037d 243d: e8 00 00 00 00 call 2442 <exc_page_fault+0x382> 243e: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 0382 2442: ff 0d 00 00 00 00 decl 0x0(%rip) # 2448 <exc_page_fault+0x388> 2444: R_X86_64_PC32 __preempt_count-0x4 0388 2448: e9 e6 fd ff ff jmp 2233 <exc_page_fault+0x173> 038d 244d: 66 2e 0f 1f 84 00 00 00 00 00 cs nopw 0x0(%rax,%rax,1) 0397 2457: 66 2e 0f 1f 84 00 00 00 00 00 cs nopw 0x0(%rax,%rax,1) 03a1 2461: 66 2e 0f 1f 84 00 00 00 00 00 cs nopw 0x0(%rax,%rax,1) 03ab 246b: 66 2e 0f 1f 84 00 00 00 00 00 cs nopw 0x0(%rax,%rax,1) 03b5 2475: 66 2e 0f 1f 84 00 00 00 00 00 cs nopw 0x0(%rax,%rax,1) 03bf 247f: 90 nop
Greeting, FYI, we noticed the following commit (built with clang-14): commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool: Add --mnop as an option to --mcount") url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git topic/ppc-kvm patch link: https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12-sv@linux.ibm.com in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): [ 152.068363][ T0] jump_label: Fatal kernel bug, unexpected op at trace_initcall_start+0xc/0x180 [ffffffff810016ec] (e9 c9 00 00 00 != 0f 1f 44 00 00)) size:5 type:1 [ 152.070368][ T0] ------------[ cut here ]------------ [ 152.071050][ T0] kernel BUG at arch/x86/kernel/jump_label.c:73! [ 152.071825][ T0] invalid opcode: 0000 [#1] SMP KASAN PTI [ 152.072427][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122 [ 152.073837][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 [ 152.075461][ T0] RIP: 0010:__jump_label_patch+0x340/0x350 [ 152.076162][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69 [ 152.078374][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086 [ 152.079159][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80 [ 152.080100][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe [ 152.081020][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53 [ 152.081936][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001 [ 152.082832][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec [ 152.083744][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 [ 152.084763][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 152.085567][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0 [ 152.086472][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 152.087407][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 152.088326][ T0] Call Trace: [ 152.088702][ T0] <TASK> [ 152.089042][ T0] ? trace_initcall_start+0xc/0x180 [ 152.089660][ T0] ? trace_initcall_start+0x1b/0x180 [ 152.090281][ T0] ? trace_initcall_start+0x11/0x180 [ 152.091237][ T0] ? jump_label_transform+0x25/0xd0 [ 152.091923][ T0] ? arch_jump_label_transform_queue+0x87/0xd0 [ 152.092651][ T0] ? __jump_label_update+0x192/0x3b0 [ 152.093320][ T0] ? static_key_enable_cpuslocked+0x129/0x250 [ 152.094020][ T0] ? rcu_lock_release+0x20/0x20 [ 152.094573][ T0] ? static_key_enable+0x16/0x20 [ 152.095167][ T0] ? tracepoint_add_func+0x87e/0x9d0 [ 152.095822][ T0] ? rcu_lock_release+0x20/0x20 [ 152.096394][ T0] ? tracepoint_probe_register+0x99/0xd0 [ 152.097055][ T0] ? rcu_lock_release+0x20/0x20 [ 152.097606][ T0] ? initcall_debug_enable+0x21/0x6b [ 152.098305][ T0] ? start_kernel+0x24b/0x4e6 [ 152.098861][ T0] ? secondary_startup_64_no_verify+0xce/0xdb [ 152.099556][ T0] </TASK> [ 152.099891][ T0] Modules linked in: [ 152.100352][ T0] ---[ end trace 0000000000000000 ]--- [ 152.100980][ T0] RIP: 0010:__jump_label_patch+0x340/0x350 [ 152.101652][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69 [ 152.103892][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086 [ 152.104544][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80 [ 152.105421][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe [ 152.106280][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53 [ 152.107182][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001 [ 152.108110][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec [ 152.109002][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 [ 152.109986][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 152.110796][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0 [ 152.111748][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 152.112686][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 152.113568][ T0] Kernel panic - not syncing: Fatal exception If you fix the issue, kindly add following tag | Reported-by: kernel test robot <yujie.liu@intel.com> | Link: https://lore.kernel.org/r/202209280801.2d5eebb5-yujie.liu@intel.com To reproduce: # build kernel cd linux cp config-6.0.0-rc2-00011-gca5e2b42c0d4 .config make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install cd <mod-install-dir> find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email # if come across any failure that blocks the test, # please remove ~/.lkp and /lkp dir to run from a clean state.
Hi all, On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote: > Greeting, > > FYI, we noticed the following commit (built with clang-14): > > commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool: Add --mnop as an option to --mcount") > url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023 > base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git topic/ppc-kvm > patch link: https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12-sv@linux.ibm.com > > in testcase: boot > > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G > > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): > > > [ 152.068363][ T0] jump_label: Fatal kernel bug, unexpected op at trace_initcall_start+0xc/0x180 [ffffffff810016ec] (e9 c9 00 00 00 != 0f 1f 44 00 00)) size:5 type:1 > [ 152.070368][ T0] ------------[ cut here ]------------ > [ 152.071050][ T0] kernel BUG at arch/x86/kernel/jump_label.c:73! > [ 152.071825][ T0] invalid opcode: 0000 [#1] SMP KASAN PTI > [ 152.072427][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122 > [ 152.073837][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 > [ 152.075461][ T0] RIP: 0010:__jump_label_patch+0x340/0x350 > [ 152.076162][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69 > [ 152.078374][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086 > [ 152.079159][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80 > [ 152.080100][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe > [ 152.081020][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53 > [ 152.081936][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001 > [ 152.082832][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec > [ 152.083744][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 > [ 152.084763][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 152.085567][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0 > [ 152.086472][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 152.087407][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 152.088326][ T0] Call Trace: > [ 152.088702][ T0] <TASK> > [ 152.089042][ T0] ? trace_initcall_start+0xc/0x180 > [ 152.089660][ T0] ? trace_initcall_start+0x1b/0x180 > [ 152.090281][ T0] ? trace_initcall_start+0x11/0x180 > [ 152.091237][ T0] ? jump_label_transform+0x25/0xd0 > [ 152.091923][ T0] ? arch_jump_label_transform_queue+0x87/0xd0 > [ 152.092651][ T0] ? __jump_label_update+0x192/0x3b0 > [ 152.093320][ T0] ? static_key_enable_cpuslocked+0x129/0x250 > [ 152.094020][ T0] ? rcu_lock_release+0x20/0x20 > [ 152.094573][ T0] ? static_key_enable+0x16/0x20 > [ 152.095167][ T0] ? tracepoint_add_func+0x87e/0x9d0 > [ 152.095822][ T0] ? rcu_lock_release+0x20/0x20 > [ 152.096394][ T0] ? tracepoint_probe_register+0x99/0xd0 > [ 152.097055][ T0] ? rcu_lock_release+0x20/0x20 > [ 152.097606][ T0] ? initcall_debug_enable+0x21/0x6b > [ 152.098305][ T0] ? start_kernel+0x24b/0x4e6 > [ 152.098861][ T0] ? secondary_startup_64_no_verify+0xce/0xdb > [ 152.099556][ T0] </TASK> > [ 152.099891][ T0] Modules linked in: > [ 152.100352][ T0] ---[ end trace 0000000000000000 ]--- > [ 152.100980][ T0] RIP: 0010:__jump_label_patch+0x340/0x350 > [ 152.101652][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69 > [ 152.103892][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086 > [ 152.104544][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80 > [ 152.105421][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe > [ 152.106280][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53 > [ 152.107182][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001 > [ 152.108110][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec > [ 152.109002][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000 > [ 152.109986][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 152.110796][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0 > [ 152.111748][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 152.112686][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 152.113568][ T0] Kernel panic - not syncing: Fatal exception > > > If you fix the issue, kindly add following tag > | Reported-by: kernel test robot <yujie.liu@intel.com> > | Link: https://lore.kernel.org/r/202209280801.2d5eebb5-yujie.liu@intel.com This crash appears to just be a symptom of objtool erroring throughout the entire build, which means things like the jump label hacks do not get applied. I see a flood of error: objtool: --mnop requires --mcount throughout the build because the configuration has CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but '--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL is enabled so '--mnop' gets passed in without '--mcount'. This should obviously be fixed somehow, perhaps by moving the '--mnop' addition into the '--mcount' if, even if that makes the line really long. A secondary issue is that it seems like if objtool encounters a fatal error like this, it should completely fail the build to make it obvious that something is wrong, rather than allowing it to continue and generate a broken kernel, especially since x86_64 requires objtool to build a working kernel at this point. Cheers, Nathan
On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote: > This crash appears to just be a symptom of objtool erroring throughout > the entire build, which means things like the jump label hacks do not > get applied. I see a flood of > > error: objtool: --mnop requires --mcount > > throughout the build because the configuration has > CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is > unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but > '--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL > is enabled so '--mnop' gets passed in without '--mcount'. This should > obviously be fixed somehow, perhaps by moving the '--mnop' addition into > the '--mcount' if, even if that makes the line really long. > > A secondary issue is that it seems like if objtool encounters a fatal > error like this, it should completely fail the build to make it obvious > that something is wrong, rather than allowing it to continue and > generate a broken kernel, especially since x86_64 requires objtool to > build a working kernel at this point. Grrr... I really dislike that objtool is capable of bricking the kernel like this. We just saw something similar in RHEL. IMO, we should just get rid of this "short JMP" feature in the jump label code, those saved three bytes aren't worth the pain. But yes, we do need to fix that config issue. And yes, maybe fatal objtool warnings should cause a build failure. We used to do that, but it brought a different sort of pain. But if objtool is going to be in the kernel's critical boot path then I guess we have to do that.
On Wed, Sep 28, 2022 at 12:13:53PM -0700, Josh Poimboeuf wrote: > On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote: > > This crash appears to just be a symptom of objtool erroring throughout > > the entire build, which means things like the jump label hacks do not > > get applied. I see a flood of > > > > error: objtool: --mnop requires --mcount > > > > throughout the build because the configuration has > > CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is > > unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but > > '--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL > > is enabled so '--mnop' gets passed in without '--mcount'. This should > > obviously be fixed somehow, perhaps by moving the '--mnop' addition into > > the '--mcount' if, even if that makes the line really long. > > > > A secondary issue is that it seems like if objtool encounters a fatal > > error like this, it should completely fail the build to make it obvious > > that something is wrong, rather than allowing it to continue and > > generate a broken kernel, especially since x86_64 requires objtool to > > build a working kernel at this point. > > Grrr... I really dislike that objtool is capable of bricking the kernel > like this. We just saw something similar in RHEL. > > IMO, we should just get rid of this "short JMP" feature in the jump > label code, those saved three bytes aren't worth the pain. > > But yes, we do need to fix that config issue. Right, I actually see that the report I was CC'd on was a part of a larger thread, where Naveen already suggested the fix for this problem, which is not clang specific it seems: https://lore.kernel.org/1663223588.wppdx3129x.naveen@linux.ibm.com/ > And yes, maybe fatal objtool warnings should cause a build failure. We > used to do that, but it brought a different sort of pain. But if > objtool is going to be in the kernel's critical boot path then I guess > we have to do that. Right, that was 644592d32837 ("objtool: Fail the kernel build on fatal errors") which was reverted in 655cf86548a3 ("objtool: Don't fail the kernel build on fatal errors") objtool should not error on warnings but it seems like it should error for invalid option combinations and other misconfiguration problems? Did this regress with commit b51277eb9775 ("objtool: Ditch subcommands")? I can see that the return code of the subcommands would be passed back via exit() (?) so objtool could fail the build if there was a true problem but after that change, objtool_run() does not have its return code checked so any errors that happen don't get passed back up. Perhaps just the following diff would resolve this? I assume we would need to look at all the different return values to know if this is safe though. Cheers, Nathan diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c index a7ecc32e3512..cda649644e32 100644 --- a/tools/objtool/objtool.c +++ b/tools/objtool/objtool.c @@ -146,7 +146,5 @@ int main(int argc, const char **argv) exec_cmd_init("objtool", UNUSED, UNUSED, UNUSED); pager_init(UNUSED); - objtool_run(argc, argv); - - return 0; + return objtool_run(argc, argv); }
diff --git a/Makefile b/Makefile index a4f71076cacb..9c1f4b038f65 100644 --- a/Makefile +++ b/Makefile @@ -857,7 +857,9 @@ ifdef CONFIG_FTRACE_MCOUNT_USE_CC endif endif ifdef CONFIG_FTRACE_MCOUNT_USE_OBJTOOL - CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT + ifdef CONFIG_HAVE_NOP_MCOUNT + CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT + endif endif ifdef CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT ifdef CONFIG_HAVE_C_RECORDMCOUNT diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f9920f1341c8..a8dd138df637 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -189,6 +189,7 @@ config X86 select HAVE_CONTEXT_TRACKING_USER_OFFSTACK if HAVE_CONTEXT_TRACKING_USER select HAVE_C_RECORDMCOUNT select HAVE_OBJTOOL_MCOUNT if HAVE_OBJTOOL + select HAVE_NOP_MCOUNT if HAVE_OBJTOOL_MCOUNT select HAVE_BUILDTIME_MCOUNT_SORT select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_CONTIGUOUS diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3fb6a99e78c4..0610078e057a 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -234,6 +234,7 @@ objtool_args = \ $(if $(CONFIG_HAVE_NOINSTR_HACK), --hacks=noinstr) \ $(if $(CONFIG_X86_KERNEL_IBT), --ibt) \ $(if $(CONFIG_FTRACE_MCOUNT_USE_OBJTOOL), --mcount) \ + $(if $(CONFIG_HAVE_NOP_MCOUNT), --mnop) \ $(if $(CONFIG_UNWINDER_ORC), --orc) \ $(if $(CONFIG_RETPOLINE), --retpoline) \ $(if $(CONFIG_RETHUNK), --rethunk) \ diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c index 24fbe803a0d3..9bd347d3c244 100644 --- a/tools/objtool/builtin-check.c +++ b/tools/objtool/builtin-check.c @@ -82,6 +82,7 @@ const struct option check_options[] = { OPT_BOOLEAN(0, "dry-run", &opts.dryrun, "don't write modifications"), OPT_BOOLEAN(0, "link", &opts.link, "object is a linked object"), OPT_BOOLEAN(0, "module", &opts.module, "object is part of a kernel module"), + OPT_BOOLEAN(0, "mnop", &opts.mnop, "nop out mcount call sites"), OPT_BOOLEAN(0, "no-unreachable", &opts.no_unreachable, "skip 'unreachable instruction' warnings"), OPT_BOOLEAN(0, "sec-address", &opts.sec_address, "print section addresses in warnings"), OPT_BOOLEAN(0, "stats", &opts.stats, "print statistics"), @@ -150,6 +151,16 @@ static bool opts_valid(void) return false; } +static bool mnop_opts_valid(void) +{ + if (opts.mnop && !opts.mcount) { + ERROR("--mnop requires --mcount"); + return false; + } + + return true; +} + static bool link_opts_valid(struct objtool_file *file) { if (opts.link) @@ -198,6 +209,9 @@ int objtool_run(int argc, const char **argv) if (!file) return 1; + if (!mnop_opts_valid()) + return 1; + if (!link_opts_valid(file)) return 1; diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 738de23cb9e8..35827e6c6df9 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1233,17 +1233,18 @@ static void annotate_call_site(struct objtool_file *file, if (opts.mcount && sym->fentry) { if (sibling) WARN_FUNC("Tail call to __fentry__ !?!?", insn->sec, insn->offset); + if (opts.mnop) { + if (reloc) { + reloc->type = R_NONE; + elf_write_reloc(file->elf, reloc); + } - if (reloc) { - reloc->type = R_NONE; - elf_write_reloc(file->elf, reloc); - } - - elf_write_insn(file->elf, insn->sec, - insn->offset, insn->len, - arch_nop_insn(insn->len)); + elf_write_insn(file->elf, insn->sec, + insn->offset, insn->len, + arch_nop_insn(insn->len)); - insn->type = INSN_NOP; + insn->type = INSN_NOP; + } list_add_tail(&insn->call_node, &file->mcount_loc_list); return; diff --git a/tools/objtool/include/objtool/builtin.h b/tools/objtool/include/objtool/builtin.h index 42a52f1a0add..0785707c5a92 100644 --- a/tools/objtool/include/objtool/builtin.h +++ b/tools/objtool/include/objtool/builtin.h @@ -31,6 +31,7 @@ struct opts { bool backup; bool dryrun; bool link; + bool mnop; bool module; bool no_unreachable; bool sec_address;