* Re: [PATCH v6 11/30] objtool: Trace instruction state changes during function validation [not found] ` <20251121095340.464045-12-alexandre.chartre@oracle.com> @ 2025-12-01 20:23 ` Nathan Chancellor 2025-12-02 1:30 ` Josh Poimboeuf 0 siblings, 1 reply; 5+ messages in thread From: Nathan Chancellor @ 2025-12-01 20:23 UTC (permalink / raw) To: Alexandre Chartre Cc: linux-kernel, mingo, jpoimboe, peterz, david.laight.linux, llvm Hi Alexandre, On Fri, Nov 21, 2025 at 10:53:21AM +0100, Alexandre Chartre wrote: > During function validation, objtool maintains a per-instruction state, > in particular to track call frame information. When tracing validation, > print any instruction state changes. > > Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> I am seeing a segfault after this change in -next as commit fcb268b47a2f ("objtool: Trace instruction state changes during function validation") when building allmodconfig with clang 21.1.6 [1] (I did not check earlier versions). $ clang --version | head -1 ClangBuiltLinux clang version 21.1.6 (https://github.com/llvm/llvm-project.git a832a5222e489298337fbb5876f8dcaf072c5cca) $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean allmodconfig drivers/scsi/qla2xxx/qla2xxx.o make[7]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 ... $ ld.lld -m elf_x86_64 --fatal-warnings -z noexecstack -r -o drivers/scsi/qla2xxx/qla2xxx.o @drivers/scsi/qla2xxx/qla2xxx.mod $ tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --ibt --cfi --mcount --mnop --orc --retpoline --rethunk --sls --static-call --uaccess --no-unreachable --link --module drivers/scsi/qla2xxx/qla2xxx.o fish: Job 1, 'tools/objtool/objtool --hacks=j…' terminated by signal SIGSEGV (Address boundary error) If there is any other information I can provide or patches I can test, I am more than happy to do so. [1]: https://mirrors.edge.kernel.org/pub/tools/llvm/files/llvm-21.1.6-x86_64.tar.xz Cheers, Nathan # bad: [95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a] Add linux-next specific files for 20251201 # good: [e69c7c175115c51c7f95394fc55425a395b3af59] Merge tag 'timers_urgent_for_v6.18_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect start '95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a' 'e69c7c175115c51c7f95394fc55425a395b3af59' # good: [87d5c4addc7e535618586e7205191a7f402288ba] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect good 87d5c4addc7e535618586e7205191a7f402288ba # good: [a4ad48eac682ccdc21e2f16b8f27abbf615d8d3d] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git git bisect good a4ad48eac682ccdc21e2f16b8f27abbf615d8d3d # bad: [b99f4ac0a6c7ccf37be14f5ef61b160b1c8a74b0] Merge branch 'driver-core-next' of https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git git bisect bad b99f4ac0a6c7ccf37be14f5ef61b160b1c8a74b0 # bad: [24cefd05bbf969c95fff3733da174e8a352c1cb2] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git git bisect bad 24cefd05bbf969c95fff3733da174e8a352c1cb2 # bad: [4fa1e8d3340bc660d72a21fc8d4c566045e488fc] Merge branch into tip/master: 'timers/clocksource' git bisect bad 4fa1e8d3340bc660d72a21fc8d4c566045e488fc # good: [51446852de95594c02d6b3b700e15b7c886534d6] Merge branch into tip/master: 'core/bugs' git bisect good 51446852de95594c02d6b3b700e15b7c886534d6 # good: [b032713af9475274762fa664ca2705372b414215] Merge branch into tip/master: 'locking/core' git bisect good b032713af9475274762fa664ca2705372b414215 # good: [9929dffce5ed7e2988e0274f4db98035508b16d9] perf/x86/intel: Fix and clean up intel_pmu_drain_arch_pebs() type use git bisect good 9929dffce5ed7e2988e0274f4db98035508b16d9 # bad: [59bfa6408214b6533d8691715cf5459e89b45b89] objtool: Build with disassembly can fail when including bdf.h git bisect bad 59bfa6408214b6533d8691715cf5459e89b45b89 # bad: [350c7ab8577a32c101a097f4c072220d9ce64f3b] objtool: Improve tracing of alternative instructions git bisect bad 350c7ab8577a32c101a097f4c072220d9ce64f3b # good: [0bb080ba6469a573bc85122153d931334d10a173] objtool: Disassemble instruction on warning or backtrace git bisect good 0bb080ba6469a573bc85122153d931334d10a173 # bad: [fcb268b47a2f4a497fdb40ef24bb9e06488b7213] objtool: Trace instruction state changes during function validation git bisect bad fcb268b47a2f4a497fdb40ef24bb9e06488b7213 # good: [de0248fbbf999d0fd3ca2aa5ba515ab78703d129] objtool: Record symbol name max length git bisect good de0248fbbf999d0fd3ca2aa5ba515ab78703d129 # good: [70589843b36fee0c6e73632469da4e5fd11f0968] objtool: Add option to trace function validation git bisect good 70589843b36fee0c6e73632469da4e5fd11f0968 # first bad commit: [fcb268b47a2f4a497fdb40ef24bb9e06488b7213] objtool: Trace instruction state changes during function validation ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v6 11/30] objtool: Trace instruction state changes during function validation 2025-12-01 20:23 ` [PATCH v6 11/30] objtool: Trace instruction state changes during function validation Nathan Chancellor @ 2025-12-02 1:30 ` Josh Poimboeuf 2025-12-02 8:34 ` Alexandre Chartre 0 siblings, 1 reply; 5+ messages in thread From: Josh Poimboeuf @ 2025-12-02 1:30 UTC (permalink / raw) To: Nathan Chancellor Cc: Alexandre Chartre, linux-kernel, mingo, peterz, david.laight.linux, llvm On Mon, Dec 01, 2025 at 01:23:29PM -0700, Nathan Chancellor wrote: > Hi Alexandre, > > On Fri, Nov 21, 2025 at 10:53:21AM +0100, Alexandre Chartre wrote: > > During function validation, objtool maintains a per-instruction state, > > in particular to track call frame information. When tracing validation, > > print any instruction state changes. > > > > Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> > > I am seeing a segfault after this change in -next as commit fcb268b47a2f > ("objtool: Trace instruction state changes during function validation") > when building allmodconfig with clang 21.1.6 [1] (I did not check > earlier versions). > > $ clang --version | head -1 > ClangBuiltLinux clang version 21.1.6 (https://github.com/llvm/llvm-project.git a832a5222e489298337fbb5876f8dcaf072c5cca) > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean allmodconfig drivers/scsi/qla2xxx/qla2xxx.o > make[7]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 > ... > > $ ld.lld -m elf_x86_64 --fatal-warnings -z noexecstack -r -o drivers/scsi/qla2xxx/qla2xxx.o @drivers/scsi/qla2xxx/qla2xxx.mod > > $ tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --ibt --cfi --mcount --mnop --orc --retpoline --rethunk --sls --static-call --uaccess --no-unreachable --link --module drivers/scsi/qla2xxx/qla2xxx.o > fish: Job 1, 'tools/objtool/objtool --hacks=j…' terminated by signal SIGSEGV (Address boundary error) > > If there is any other information I can provide or patches I can test, I > am more than happy to do so. > > [1]: https://mirrors.edge.kernel.org/pub/tools/llvm/files/llvm-21.1.6-x86_64.tar.xz Objtool is overflowing the stack due to the large number of jumps it has to follow in that code, thanks to kasan. The above mentioned patch fcb268b47a2f ("objtool: Trace instruction state changes during function validation") added a 328-byte struct to the stack in validate_insn() which drastically increased the amount of stack size needed. I suppose we could hack a fix by making it a static local variable, like below. Or, objtool could setrlimit(RLIMIT_STACK) to 16MB? diff --git a/tools/objtool/check.c b/tools/objtool/check.c index a02f8db75827..206b8589d82b 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -3678,7 +3678,7 @@ static int validate_insn(struct objtool_file *file, struct symbol *func, bool *dead_end) { /* prev_state is not used if there is no disassembly support */ - struct insn_state prev_state __maybe_unused; + static struct insn_state prev_state __maybe_unused; struct alternative *alt; u8 visited; int ret; ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v6 11/30] objtool: Trace instruction state changes during function validation 2025-12-02 1:30 ` Josh Poimboeuf @ 2025-12-02 8:34 ` Alexandre Chartre 2025-12-02 16:13 ` Josh Poimboeuf 0 siblings, 1 reply; 5+ messages in thread From: Alexandre Chartre @ 2025-12-02 8:34 UTC (permalink / raw) To: Josh Poimboeuf, Nathan Chancellor Cc: alexandre.chartre, linux-kernel, mingo, peterz, david.laight.linux, llvm On 12/2/25 02:30, Josh Poimboeuf wrote: > On Mon, Dec 01, 2025 at 01:23:29PM -0700, Nathan Chancellor wrote: >> Hi Alexandre, >> >> On Fri, Nov 21, 2025 at 10:53:21AM +0100, Alexandre Chartre wrote: >>> During function validation, objtool maintains a per-instruction state, >>> in particular to track call frame information. When tracing validation, >>> print any instruction state changes. >>> >>> Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> >> >> I am seeing a segfault after this change in -next as commit fcb268b47a2f >> ("objtool: Trace instruction state changes during function validation") >> when building allmodconfig with clang 21.1.6 [1] (I did not check >> earlier versions). >> >> $ clang --version | head -1 >> ClangBuiltLinux clang version 21.1.6 (https://github.com/llvm/llvm-project.git a832a5222e489298337fbb5876f8dcaf072c5cca) >> >> $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean allmodconfig drivers/scsi/qla2xxx/qla2xxx.o >> make[7]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 >> ... >> >> $ ld.lld -m elf_x86_64 --fatal-warnings -z noexecstack -r -o drivers/scsi/qla2xxx/qla2xxx.o @drivers/scsi/qla2xxx/qla2xxx.mod >> >> $ tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --ibt --cfi --mcount --mnop --orc --retpoline --rethunk --sls --static-call --uaccess --no-unreachable --link --module drivers/scsi/qla2xxx/qla2xxx.o >> fish: Job 1, 'tools/objtool/objtool --hacks=j…' terminated by signal SIGSEGV (Address boundary error) >> >> If there is any other information I can provide or patches I can test, I >> am more than happy to do so. >> >> [1]: https://mirrors.edge.kernel.org/pub/tools/llvm/files/llvm-21.1.6-x86_64.tar.xz > > Objtool is overflowing the stack due to the large number of jumps it has > to follow in that code, thanks to kasan. The above mentioned patch > > fcb268b47a2f ("objtool: Trace instruction state changes during function validation") > > added a 328-byte struct to the stack in validate_insn() which > drastically increased the amount of stack size needed. > > I suppose we could hack a fix by making it a static local variable, like > below. > > Or, objtool could setrlimit(RLIMIT_STACK) to 16MB? > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index a02f8db75827..206b8589d82b 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -3678,7 +3678,7 @@ static int validate_insn(struct objtool_file *file, struct symbol *func, > bool *dead_end) > { > /* prev_state is not used if there is no disassembly support */ > - struct insn_state prev_state __maybe_unused; > + static struct insn_state prev_state __maybe_unused; > struct alternative *alt; > u8 visited; > int ret; static looks good enough to me. Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Thanks, alex. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v6 11/30] objtool: Trace instruction state changes during function validation 2025-12-02 8:34 ` Alexandre Chartre @ 2025-12-02 16:13 ` Josh Poimboeuf 2025-12-02 18:09 ` David Laight 0 siblings, 1 reply; 5+ messages in thread From: Josh Poimboeuf @ 2025-12-02 16:13 UTC (permalink / raw) To: Alexandre Chartre Cc: Nathan Chancellor, linux-kernel, mingo, peterz, david.laight.linux, llvm On Tue, Dec 02, 2025 at 09:34:20AM +0100, Alexandre Chartre wrote: > > On 12/2/25 02:30, Josh Poimboeuf wrote: > > On Mon, Dec 01, 2025 at 01:23:29PM -0700, Nathan Chancellor wrote: > > > Hi Alexandre, > > > > > > On Fri, Nov 21, 2025 at 10:53:21AM +0100, Alexandre Chartre wrote: > > > > During function validation, objtool maintains a per-instruction state, > > > > in particular to track call frame information. When tracing validation, > > > > print any instruction state changes. > > > > > > > > Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com> > > > > > > I am seeing a segfault after this change in -next as commit fcb268b47a2f > > > ("objtool: Trace instruction state changes during function validation") > > > when building allmodconfig with clang 21.1.6 [1] (I did not check > > > earlier versions). > > > > > > $ clang --version | head -1 > > > ClangBuiltLinux clang version 21.1.6 (https://github.com/llvm/llvm-project.git a832a5222e489298337fbb5876f8dcaf072c5cca) > > > > > > $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean allmodconfig drivers/scsi/qla2xxx/qla2xxx.o > > > make[7]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 > > > ... > > > > > > $ ld.lld -m elf_x86_64 --fatal-warnings -z noexecstack -r -o drivers/scsi/qla2xxx/qla2xxx.o @drivers/scsi/qla2xxx/qla2xxx.mod > > > > > > $ tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --ibt --cfi --mcount --mnop --orc --retpoline --rethunk --sls --static-call --uaccess --no-unreachable --link --module drivers/scsi/qla2xxx/qla2xxx.o > > > fish: Job 1, 'tools/objtool/objtool --hacks=j…' terminated by signal SIGSEGV (Address boundary error) > > > > > > If there is any other information I can provide or patches I can test, I > > > am more than happy to do so. > > > > > > [1]: https://mirrors.edge.kernel.org/pub/tools/llvm/files/llvm-21.1.6-x86_64.tar.xz > > > > Objtool is overflowing the stack due to the large number of jumps it has > > to follow in that code, thanks to kasan. The above mentioned patch > > > > fcb268b47a2f ("objtool: Trace instruction state changes during function validation") > > > > added a 328-byte struct to the stack in validate_insn() which > > drastically increased the amount of stack size needed. > > > > I suppose we could hack a fix by making it a static local variable, like > > below. > > > > Or, objtool could setrlimit(RLIMIT_STACK) to 16MB? > > > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > > index a02f8db75827..206b8589d82b 100644 > > --- a/tools/objtool/check.c > > +++ b/tools/objtool/check.c > > @@ -3678,7 +3678,7 @@ static int validate_insn(struct objtool_file *file, struct symbol *func, > > bool *dead_end) > > { > > /* prev_state is not used if there is no disassembly support */ > > - struct insn_state prev_state __maybe_unused; > > + static struct insn_state prev_state __maybe_unused; > > struct alternative *alt; > > u8 visited; > > int ret; > > static looks good enough to me. > > Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> > > Thanks, The static local bothered me, I went with a different approach to move that variable (and its usage) to handle_insn_ops(). Will post shortly. -- Josh ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v6 11/30] objtool: Trace instruction state changes during function validation 2025-12-02 16:13 ` Josh Poimboeuf @ 2025-12-02 18:09 ` David Laight 0 siblings, 0 replies; 5+ messages in thread From: David Laight @ 2025-12-02 18:09 UTC (permalink / raw) To: Josh Poimboeuf Cc: Alexandre Chartre, Nathan Chancellor, linux-kernel, mingo, peterz, llvm On Tue, 2 Dec 2025 08:13:21 -0800 Josh Poimboeuf <jpoimboe@kernel.org> wrote: ... > The static local bothered me, I went with a different approach to move > that variable (and its usage) to handle_insn_ops(). Will post shortly. > Does look a little wrong inside a recursively called function. How does the code get on for 32bit builds? I'd guess they have a lot less stack available? David ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-02 18:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20251121095340.464045-1-alexandre.chartre@oracle.com>
[not found] ` <20251121095340.464045-12-alexandre.chartre@oracle.com>
2025-12-01 20:23 ` [PATCH v6 11/30] objtool: Trace instruction state changes during function validation Nathan Chancellor
2025-12-02 1:30 ` Josh Poimboeuf
2025-12-02 8:34 ` Alexandre Chartre
2025-12-02 16:13 ` Josh Poimboeuf
2025-12-02 18:09 ` David Laight
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox