* [next] x86_64 defconfig failed with clang-10 @ 2021-05-14 18:12 Naresh Kamboju 2021-05-14 20:54 ` Nathan Chancellor 0 siblings, 1 reply; 6+ messages in thread From: Naresh Kamboju @ 2021-05-14 18:12 UTC (permalink / raw) To: clang-built-linux, Linux-Next Mailing List Cc: Nathan Chancellor, Nick Desaulniers, lkft-triage, Stephen Rothwell, Arnd Bergmann My two cents, We know clang-10 support is stopped, but our build system is still running these builds with clang-10. one of those observations is, The LKFT build failures were noticed while building x86_64 and i386 with clang-10 on linux next-20210514 tag. - x86_64 (defconfig) with clang-10 - FAIL - i386 (defconfig) with clang-10 - FAIL - x86_64 (defconfig) with clang-11 - PASS - i386 (defconfig) with clang-11 - PASS - x86_64 (defconfig) with clang-12 - PASS - i386 (defconfig) with clang-12 - PASS Build log: ---------- make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache clang' drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_relocate_parse_slow()+0x427: stack state mismatch: cfa1=4+120 cfa2=-1+0 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations()+0x1d5: stack state mismatch: cfa1=4+104 cfa2=-1+0 x86_64-linux-gnu-ld: arch/x86/kernel/kprobes/opt.o: in function `arch_prepare_optimized_kprobe': opt.c:(.text+0x798): undefined reference to `__compiletime_assert_251' make[1]: *** [/builds/linux/Makefile:1272: vmlinux] Error 1 ref: https://builds.tuxbuild.com/1sW0ag5finSjVuErrrzeunjj1nx/ -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [next] x86_64 defconfig failed with clang-10 2021-05-14 18:12 [next] x86_64 defconfig failed with clang-10 Naresh Kamboju @ 2021-05-14 20:54 ` Nathan Chancellor 2021-05-17 20:39 ` Nick Desaulniers 0 siblings, 1 reply; 6+ messages in thread From: Nathan Chancellor @ 2021-05-14 20:54 UTC (permalink / raw) To: Naresh Kamboju, clang-built-linux, Linux-Next Mailing List Cc: Nick Desaulniers, lkft-triage, Stephen Rothwell, Arnd Bergmann, Hyeonggon Yoo, Vlastimil Babka, Andrew Morton On 5/14/2021 11:12 AM, Naresh Kamboju wrote: > My two cents, > We know clang-10 support is stopped, but our build system is still running For the record, we are still building with clang-10 as that is the minimum supported version for the kernel. > these builds with clang-10. one of those observations is, > > The LKFT build failures were noticed while building x86_64 and i386 with > clang-10 on linux next-20210514 tag. > > - x86_64 (defconfig) with clang-10 - FAIL > - i386 (defconfig) with clang-10 - FAIL > - x86_64 (defconfig) with clang-11 - PASS > - i386 (defconfig) with clang-11 - PASS > - x86_64 (defconfig) with clang-12 - PASS > - i386 (defconfig) with clang-12 - PASS > > Build log: > ---------- > make --silent --keep-going --jobs=8 > O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=x86_64 > CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache > clang' > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > eb_relocate_parse_slow()+0x427: stack state mismatch: cfa1=4+120 > cfa2=-1+0 > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > eb_copy_relocations()+0x1d5: stack state mismatch: cfa1=4+104 > cfa2=-1+0 > x86_64-linux-gnu-ld: arch/x86/kernel/kprobes/opt.o: in function > `arch_prepare_optimized_kprobe': > opt.c:(.text+0x798): undefined reference to `__compiletime_assert_251' > make[1]: *** [/builds/linux/Makefile:1272: vmlinux] Error 1 Thanks for the report. Our CI also reported this: https://github.com/ClangBuiltLinux/continuous-integration2/runs/2582534773?check_suite_focus=true My bisect landed on "mm, slub: change run-time assertion in kmalloc_index() to compile-time" in -next (I have added the author and reviewers to cc): $ git bisect log # bad: [cd557f1c605fc5a2c0eb0b540610f50dc67dd849] Add linux-next specific files for 20210514 # good: [315d99318179b9cd5077ccc9f7f26a164c9fa998] Merge tag 'pm-5.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect start 'cd557f1c605fc5a2c0eb0b540610f50dc67dd849' '315d99318179b9cd5077ccc9f7f26a164c9fa998' # good: [9634d7cb3c506ae886a5136d12b4af696b9cee8a] Merge remote-tracking branch 'drm-misc/for-linux-next' git bisect good 9634d7cb3c506ae886a5136d12b4af696b9cee8a # good: [294636a24ae819a7caf0807d05d8eb5b964ec06f] Merge remote-tracking branch 'rcu/rcu/next' git bisect good 294636a24ae819a7caf0807d05d8eb5b964ec06f # good: [cb753d0611f912439c8e814f4254d15fa8fa1d75] Merge remote-tracking branch 'gpio-brgl/gpio/for-next' git bisect good cb753d0611f912439c8e814f4254d15fa8fa1d75 # bad: [b1e7389449084b74a044a70860c6a1c7466781cb] lib/string_helpers: switch to use BIT() macro git bisect bad b1e7389449084b74a044a70860c6a1c7466781cb # bad: [bf5570ed0654a21000e5dad9243ea1ba30bfe208] kasan: use dump_stack_lvl(KERN_ERR) to print stacks git bisect bad bf5570ed0654a21000e5dad9243ea1ba30bfe208 # bad: [4a292ff7a819404039588c7a9af272aca22c869e] fixup! mm: gup: pack has_pinned in MMF_HAS_PINNED git bisect bad 4a292ff7a819404039588c7a9af272aca22c869e # good: [93e440dd0e482b6cde20630d58016a451fb2b431] ocfs2: fix snprintf() checking git bisect good 93e440dd0e482b6cde20630d58016a451fb2b431 # good: [f32aeffdb407b6390ef17ccac87e1a1a76663354] slub: remove resiliency_test() function git bisect good f32aeffdb407b6390ef17ccac87e1a1a76663354 # bad: [2c9b936dae88dbdbb28666a741c87b08abb1b755] mm/page-writeback: update the comment of Dirty position control git bisect bad 2c9b936dae88dbdbb28666a741c87b08abb1b755 # bad: [597da4750c8e8f5f304419f3c66b713a88f3ebbe] tools/vm/page_owner_sort.c: check malloc() return git bisect bad 597da4750c8e8f5f304419f3c66b713a88f3ebbe # bad: [0ec3603432be3abba93ee7aa512cb6d83dd1c291] kfence: test: fix for "mm, slub: change run-time assertion in kmalloc_index() to compile-time" git bisect bad 0ec3603432be3abba93ee7aa512cb6d83dd1c291 # bad: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: change run-time assertion in kmalloc_index() to compile-time git bisect bad ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 # first bad commit: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: change run-time assertion in kmalloc_index() to compile-time https://git.kernel.org/next/linux-next/c/ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 It looks like LLVM fixed this in http://github.com/llvm/llvm-project/commit/6aabb109becfee37126ff7db3d41a41b5779f359. I think this happens because arch_prepare_optimized_kprobe() calls kzalloc() with a size of MAX_OPTINSN_SIZE, which is #define MAX_OPTINSN_SIZE \ (((unsigned long)optprobe_template_end - \ (unsigned long)optprobe_template_entry) + \ MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE) and the optprobe_template_{end,entry} are not evaluated as constants. I am not sure what the solution is. There seem to be a growing list of issues with LLVM 10 that were fixed in LLVM 11, which might necessitate requiring LLVM 11 and newer to build the kernel, given this affects a defconfig. Cheers, Nathan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [next] x86_64 defconfig failed with clang-10 2021-05-14 20:54 ` Nathan Chancellor @ 2021-05-17 20:39 ` Nick Desaulniers 2021-05-18 0:55 ` Nathan Chancellor ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Nick Desaulniers @ 2021-05-17 20:39 UTC (permalink / raw) To: Nathan Chancellor Cc: Naresh Kamboju, clang-built-linux, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Hyeonggon Yoo, Vlastimil Babka, Andrew Morton On Fri, May 14, 2021 at 1:54 PM Nathan Chancellor <nathan@kernel.org> wrote: > > On 5/14/2021 11:12 AM, Naresh Kamboju wrote: > > My two cents, > > We know clang-10 support is stopped, but our build system is still running > > For the record, we are still building with clang-10 as that is the > minimum supported version for the kernel. > > > these builds with clang-10. one of those observations is, > > > > The LKFT build failures were noticed while building x86_64 and i386 with > > clang-10 on linux next-20210514 tag. > > > > - x86_64 (defconfig) with clang-10 - FAIL > > - i386 (defconfig) with clang-10 - FAIL > > - x86_64 (defconfig) with clang-11 - PASS > > - i386 (defconfig) with clang-11 - PASS > > - x86_64 (defconfig) with clang-12 - PASS > > - i386 (defconfig) with clang-12 - PASS > > > > Build log: > > ---------- > > make --silent --keep-going --jobs=8 > > O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=x86_64 > > CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache > > clang' > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > > eb_relocate_parse_slow()+0x427: stack state mismatch: cfa1=4+120 > > cfa2=-1+0 > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > > eb_copy_relocations()+0x1d5: stack state mismatch: cfa1=4+104 > > cfa2=-1+0 > > x86_64-linux-gnu-ld: arch/x86/kernel/kprobes/opt.o: in function > > `arch_prepare_optimized_kprobe': > > opt.c:(.text+0x798): undefined reference to `__compiletime_assert_251' > > make[1]: *** [/builds/linux/Makefile:1272: vmlinux] Error 1 > > Thanks for the report. Our CI also reported this: > > https://github.com/ClangBuiltLinux/continuous-integration2/runs/2582534773?check_suite_focus=true > > My bisect landed on "mm, slub: change run-time assertion in > kmalloc_index() to compile-time" in -next (I have added the author and > reviewers to cc): > > $ git bisect log > # bad: [cd557f1c605fc5a2c0eb0b540610f50dc67dd849] Add linux-next > specific files for 20210514 > # good: [315d99318179b9cd5077ccc9f7f26a164c9fa998] Merge tag > 'pm-5.13-rc2' of > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > git bisect start 'cd557f1c605fc5a2c0eb0b540610f50dc67dd849' > '315d99318179b9cd5077ccc9f7f26a164c9fa998' > # good: [9634d7cb3c506ae886a5136d12b4af696b9cee8a] Merge remote-tracking > branch 'drm-misc/for-linux-next' > git bisect good 9634d7cb3c506ae886a5136d12b4af696b9cee8a > # good: [294636a24ae819a7caf0807d05d8eb5b964ec06f] Merge remote-tracking > branch 'rcu/rcu/next' > git bisect good 294636a24ae819a7caf0807d05d8eb5b964ec06f > # good: [cb753d0611f912439c8e814f4254d15fa8fa1d75] Merge remote-tracking > branch 'gpio-brgl/gpio/for-next' > git bisect good cb753d0611f912439c8e814f4254d15fa8fa1d75 > # bad: [b1e7389449084b74a044a70860c6a1c7466781cb] lib/string_helpers: > switch to use BIT() macro > git bisect bad b1e7389449084b74a044a70860c6a1c7466781cb > # bad: [bf5570ed0654a21000e5dad9243ea1ba30bfe208] kasan: use > dump_stack_lvl(KERN_ERR) to print stacks > git bisect bad bf5570ed0654a21000e5dad9243ea1ba30bfe208 > # bad: [4a292ff7a819404039588c7a9af272aca22c869e] fixup! mm: gup: pack > has_pinned in MMF_HAS_PINNED > git bisect bad 4a292ff7a819404039588c7a9af272aca22c869e > # good: [93e440dd0e482b6cde20630d58016a451fb2b431] ocfs2: fix snprintf() > checking > git bisect good 93e440dd0e482b6cde20630d58016a451fb2b431 > # good: [f32aeffdb407b6390ef17ccac87e1a1a76663354] slub: remove > resiliency_test() function > git bisect good f32aeffdb407b6390ef17ccac87e1a1a76663354 > # bad: [2c9b936dae88dbdbb28666a741c87b08abb1b755] mm/page-writeback: > update the comment of Dirty position control > git bisect bad 2c9b936dae88dbdbb28666a741c87b08abb1b755 > # bad: [597da4750c8e8f5f304419f3c66b713a88f3ebbe] > tools/vm/page_owner_sort.c: check malloc() return > git bisect bad 597da4750c8e8f5f304419f3c66b713a88f3ebbe > # bad: [0ec3603432be3abba93ee7aa512cb6d83dd1c291] kfence: test: fix for > "mm, slub: change run-time assertion in kmalloc_index() to compile-time" > git bisect bad 0ec3603432be3abba93ee7aa512cb6d83dd1c291 > # bad: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: change > run-time assertion in kmalloc_index() to compile-time > git bisect bad ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 > # first bad commit: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: > change run-time assertion in kmalloc_index() to compile-time > > https://git.kernel.org/next/linux-next/c/ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 > > It looks like LLVM fixed this in > http://github.com/llvm/llvm-project/commit/6aabb109becfee37126ff7db3d41a41b5779f359. > > I think this happens because arch_prepare_optimized_kprobe() calls > kzalloc() with a size of MAX_OPTINSN_SIZE, which is > > #define MAX_OPTINSN_SIZE \ > (((unsigned long)optprobe_template_end - \ > (unsigned long)optprobe_template_entry) + \ > MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE) > > and the optprobe_template_{end,entry} are not evaluated as constants. > > I am not sure what the solution is. There seem to be a growing list of > issues with LLVM 10 that were fixed in LLVM 11, which might necessitate > requiring LLVM 11 and newer to build the kernel, given this affects a > defconfig. If we can make the compile time validation done instead at runtime for clang-10, that would be preferable. Then when we drop clang-10 support, we can revert that. Looking at the diff, I think we could reinstate parts like so: diff --git a/include/linux/slab.h b/include/linux/slab.h index 9d316aac0aba..4c13e2cd415c 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -412,6 +412,9 @@ static __always_inline unsigned int __kmalloc_index(size_t size, if (size <= 8 * 1024 * 1024) return 23; if (size <= 16 * 1024 * 1024) return 24; if (size <= 32 * 1024 * 1024) return 25; +#if CLANG_VERSION <= 100000 + if (size <= 64 * 1024 * 1024) return 26; +#endif if (size_is_constant) BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); diff --git a/mm/slab_common.c b/mm/slab_common.c index a0b8ffeae4ae..ecb6104b9dbb 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -799,6 +799,9 @@ const struct kmalloc_info_struct kmalloc_info[] __initconst = { INIT_KMALLOC_INFO(8388608, 8M), INIT_KMALLOC_INFO(16777216, 16M), INIT_KMALLOC_INFO(33554432, 32M) +#if CLANG_VERSION <= 10000 + ,INIT_KMALLOC_INFO(67108864, 64M) +#endif }; /* -- Thanks, ~Nick Desaulniers ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [next] x86_64 defconfig failed with clang-10 2021-05-17 20:39 ` Nick Desaulniers @ 2021-05-18 0:55 ` Nathan Chancellor 2021-05-18 1:04 ` Hyeonggon Yoo 2021-05-18 1:11 ` Hyeonggon Yoo 2 siblings, 0 replies; 6+ messages in thread From: Nathan Chancellor @ 2021-05-18 0:55 UTC (permalink / raw) To: Nick Desaulniers Cc: Naresh Kamboju, clang-built-linux, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Hyeonggon Yoo, Vlastimil Babka, Andrew Morton On Mon, May 17, 2021 at 01:39:46PM -0700, Nick Desaulniers wrote: > On Fri, May 14, 2021 at 1:54 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > On 5/14/2021 11:12 AM, Naresh Kamboju wrote: > > > My two cents, > > > We know clang-10 support is stopped, but our build system is still running > > > > For the record, we are still building with clang-10 as that is the > > minimum supported version for the kernel. > > > > > these builds with clang-10. one of those observations is, > > > > > > The LKFT build failures were noticed while building x86_64 and i386 with > > > clang-10 on linux next-20210514 tag. > > > > > > - x86_64 (defconfig) with clang-10 - FAIL > > > - i386 (defconfig) with clang-10 - FAIL > > > - x86_64 (defconfig) with clang-11 - PASS > > > - i386 (defconfig) with clang-11 - PASS > > > - x86_64 (defconfig) with clang-12 - PASS > > > - i386 (defconfig) with clang-12 - PASS > > > > > > Build log: > > > ---------- > > > make --silent --keep-going --jobs=8 > > > O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=x86_64 > > > CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache > > > clang' > > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > > > eb_relocate_parse_slow()+0x427: stack state mismatch: cfa1=4+120 > > > cfa2=-1+0 > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > > > eb_copy_relocations()+0x1d5: stack state mismatch: cfa1=4+104 > > > cfa2=-1+0 > > > x86_64-linux-gnu-ld: arch/x86/kernel/kprobes/opt.o: in function > > > `arch_prepare_optimized_kprobe': > > > opt.c:(.text+0x798): undefined reference to `__compiletime_assert_251' > > > make[1]: *** [/builds/linux/Makefile:1272: vmlinux] Error 1 > > > > Thanks for the report. Our CI also reported this: > > > > https://github.com/ClangBuiltLinux/continuous-integration2/runs/2582534773?check_suite_focus=true > > > > My bisect landed on "mm, slub: change run-time assertion in > > kmalloc_index() to compile-time" in -next (I have added the author and > > reviewers to cc): > > > > $ git bisect log > > # bad: [cd557f1c605fc5a2c0eb0b540610f50dc67dd849] Add linux-next > > specific files for 20210514 > > # good: [315d99318179b9cd5077ccc9f7f26a164c9fa998] Merge tag > > 'pm-5.13-rc2' of > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > > git bisect start 'cd557f1c605fc5a2c0eb0b540610f50dc67dd849' > > '315d99318179b9cd5077ccc9f7f26a164c9fa998' > > # good: [9634d7cb3c506ae886a5136d12b4af696b9cee8a] Merge remote-tracking > > branch 'drm-misc/for-linux-next' > > git bisect good 9634d7cb3c506ae886a5136d12b4af696b9cee8a > > # good: [294636a24ae819a7caf0807d05d8eb5b964ec06f] Merge remote-tracking > > branch 'rcu/rcu/next' > > git bisect good 294636a24ae819a7caf0807d05d8eb5b964ec06f > > # good: [cb753d0611f912439c8e814f4254d15fa8fa1d75] Merge remote-tracking > > branch 'gpio-brgl/gpio/for-next' > > git bisect good cb753d0611f912439c8e814f4254d15fa8fa1d75 > > # bad: [b1e7389449084b74a044a70860c6a1c7466781cb] lib/string_helpers: > > switch to use BIT() macro > > git bisect bad b1e7389449084b74a044a70860c6a1c7466781cb > > # bad: [bf5570ed0654a21000e5dad9243ea1ba30bfe208] kasan: use > > dump_stack_lvl(KERN_ERR) to print stacks > > git bisect bad bf5570ed0654a21000e5dad9243ea1ba30bfe208 > > # bad: [4a292ff7a819404039588c7a9af272aca22c869e] fixup! mm: gup: pack > > has_pinned in MMF_HAS_PINNED > > git bisect bad 4a292ff7a819404039588c7a9af272aca22c869e > > # good: [93e440dd0e482b6cde20630d58016a451fb2b431] ocfs2: fix snprintf() > > checking > > git bisect good 93e440dd0e482b6cde20630d58016a451fb2b431 > > # good: [f32aeffdb407b6390ef17ccac87e1a1a76663354] slub: remove > > resiliency_test() function > > git bisect good f32aeffdb407b6390ef17ccac87e1a1a76663354 > > # bad: [2c9b936dae88dbdbb28666a741c87b08abb1b755] mm/page-writeback: > > update the comment of Dirty position control > > git bisect bad 2c9b936dae88dbdbb28666a741c87b08abb1b755 > > # bad: [597da4750c8e8f5f304419f3c66b713a88f3ebbe] > > tools/vm/page_owner_sort.c: check malloc() return > > git bisect bad 597da4750c8e8f5f304419f3c66b713a88f3ebbe > > # bad: [0ec3603432be3abba93ee7aa512cb6d83dd1c291] kfence: test: fix for > > "mm, slub: change run-time assertion in kmalloc_index() to compile-time" > > git bisect bad 0ec3603432be3abba93ee7aa512cb6d83dd1c291 > > # bad: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: change > > run-time assertion in kmalloc_index() to compile-time > > git bisect bad ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 > > # first bad commit: [ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51] mm, slub: > > change run-time assertion in kmalloc_index() to compile-time > > > > https://git.kernel.org/next/linux-next/c/ff3daafe3fd3e54c8cf6aeb865099c7bb02e5c51 > > > > It looks like LLVM fixed this in > > http://github.com/llvm/llvm-project/commit/6aabb109becfee37126ff7db3d41a41b5779f359. > > > > I think this happens because arch_prepare_optimized_kprobe() calls > > kzalloc() with a size of MAX_OPTINSN_SIZE, which is > > > > #define MAX_OPTINSN_SIZE \ > > (((unsigned long)optprobe_template_end - \ > > (unsigned long)optprobe_template_entry) + \ > > MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE) > > > > and the optprobe_template_{end,entry} are not evaluated as constants. > > > > I am not sure what the solution is. There seem to be a growing list of > > issues with LLVM 10 that were fixed in LLVM 11, which might necessitate > > requiring LLVM 11 and newer to build the kernel, given this affects a > > defconfig. > > If we can make the compile time validation done instead at runtime for > clang-10, that would be preferable. Then when we drop clang-10 > support, we can revert that. Looking at the diff, I think we could > reinstate parts like so: > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 9d316aac0aba..4c13e2cd415c 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -412,6 +412,9 @@ static __always_inline unsigned int > __kmalloc_index(size_t size, > if (size <= 8 * 1024 * 1024) return 23; > if (size <= 16 * 1024 * 1024) return 24; > if (size <= 32 * 1024 * 1024) return 25; > +#if CLANG_VERSION <= 100000 > + if (size <= 64 * 1024 * 1024) return 26; > +#endif > > if (size_is_constant) > BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); > diff --git a/mm/slab_common.c b/mm/slab_common.c > index a0b8ffeae4ae..ecb6104b9dbb 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -799,6 +799,9 @@ const struct kmalloc_info_struct kmalloc_info[] > __initconst = { > INIT_KMALLOC_INFO(8388608, 8M), > INIT_KMALLOC_INFO(16777216, 16M), > INIT_KMALLOC_INFO(33554432, 32M) > +#if CLANG_VERSION <= 10000 > + ,INIT_KMALLOC_INFO(67108864, 64M) > +#endif > }; > > /* I adapted that patch as below but unfortunately, that did not resolve anything: $ make -skj$(nproc) LLVM=1 LLVM_IAS=1 O=build/x86_64 distclean defconfig arch/x86/kernel/kprobes/opt.o $ llvm-readelf -s build/x86_64/arch/x86/kernel/kprobes/opt.o | grep __compile 10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __compiletime_assert_251 I did suggest another change in the original patch thread: https://lore.kernel.org/r/YKC9CeAfw3aBmHTU@archlinux-ax161/ Cheers, Nathan -------------------------------------------------------- diff --git a/include/linux/slab.h b/include/linux/slab.h index 9d316aac0aba..c55c09544538 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -412,6 +412,9 @@ static __always_inline unsigned int __kmalloc_index(size_t size, if (size <= 8 * 1024 * 1024) return 23; if (size <= 16 * 1024 * 1024) return 24; if (size <= 32 * 1024 * 1024) return 25; +#if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 110000 + if (size <= 64 * 1024 * 1024) return 26; +#endif if (size_is_constant) BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); diff --git a/mm/slab_common.c b/mm/slab_common.c index a0b8ffeae4ae..bd3fa2ed7e43 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -799,6 +799,9 @@ const struct kmalloc_info_struct kmalloc_info[] __initconst = { INIT_KMALLOC_INFO(8388608, 8M), INIT_KMALLOC_INFO(16777216, 16M), INIT_KMALLOC_INFO(33554432, 32M) +#if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 110000 + ,INIT_KMALLOC_INFO(67108864, 64M) +#endif }; /* ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [next] x86_64 defconfig failed with clang-10 2021-05-17 20:39 ` Nick Desaulniers 2021-05-18 0:55 ` Nathan Chancellor @ 2021-05-18 1:04 ` Hyeonggon Yoo 2021-05-18 1:11 ` Hyeonggon Yoo 2 siblings, 0 replies; 6+ messages in thread From: Hyeonggon Yoo @ 2021-05-18 1:04 UTC (permalink / raw) To: Nick Desaulniers Cc: Nathan Chancellor, Naresh Kamboju, clang-built-linux, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Vlastimil Babka, Andrew Morton On Mon, May 17, 2021 at 01:39:46PM -0700, Nick Desaulniers wrote: > If we can make the compile time validation done instead at runtime for > clang-10, that would be preferable. Then when we drop clang-10 > support, we can revert that. Looking at the diff, I think we could > reinstate parts like so: > +#if CLANG_VERSION <= 100000 > + if (size <= 64 * 1024 * 1024) return 26; > +#endif > +#if CLANG_VERSION <= 10000 > + ,INIT_KMALLOC_INFO(67108864, 64M) > +#endif I see no reason to add those lines. I removed them because kmalloc isn't written to support 64MB size, and it doesn't depend on clang version. am I misunderstanding your patch? the problem here is clang-10 is mis-understanding constant argument as non-constant. and the patch that Nathan linked makes compiler do run-time evaluation when clang version is less than 11. Thanks, Hyeonggon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [next] x86_64 defconfig failed with clang-10 2021-05-17 20:39 ` Nick Desaulniers 2021-05-18 0:55 ` Nathan Chancellor 2021-05-18 1:04 ` Hyeonggon Yoo @ 2021-05-18 1:11 ` Hyeonggon Yoo 2 siblings, 0 replies; 6+ messages in thread From: Hyeonggon Yoo @ 2021-05-18 1:11 UTC (permalink / raw) To: Nick Desaulniers Cc: Nathan Chancellor, Naresh Kamboju, clang-built-linux, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Vlastimil Babka, Andrew Morton > I see no reason to add those lines. > I removed the because kmalloc isn't written to support 64Mb size, > and it doesn't depend on clang version. I mean, not kmalloc, but kmalloc_caches that kmalloc uses when size is constant. It supports only up to 32MB. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-05-18 1:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-14 18:12 [next] x86_64 defconfig failed with clang-10 Naresh Kamboju 2021-05-14 20:54 ` Nathan Chancellor 2021-05-17 20:39 ` Nick Desaulniers 2021-05-18 0:55 ` Nathan Chancellor 2021-05-18 1:04 ` Hyeonggon Yoo 2021-05-18 1:11 ` Hyeonggon Yoo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.