- 23 4月, 2020 2 次提交
-
-
由 Julien Thierry 提交于
Sometimes, WARN_FUNC() and other users of symbol_by_offset() will associate the first instruction of a symbol with the symbol preceding it. This is because symbol->offset + symbol->len is already outside of the symbol's range. Fixes: 2a362ecc ("objtool: Optimize find_symbol_*() and read_symbols()") Signed-off-by: NJulien Thierry <jthierry@redhat.com> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
-
由 Peter Zijlstra 提交于
Apparently there's people doing 64bit builds on 32bit machines. Fixes: 74b873e4 ("objtool: Optimize find_rela_by_dest_range()") Reported-by: youling257@gmail.com Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
-
- 14 4月, 2020 5 次提交
-
-
由 Josh Poimboeuf 提交于
If func is NULL, a seg fault can result. This is a theoretical issue which was found by Coverity, ID: 1492002 ("Dereference after null check"). Fixes: c705cecc ("objtool: Track original function across branches") Reported-by: NGustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/afc628693a37acd287e843bcc5c0430263d93c74.1585761021.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
If a switch jump table's indirect branch is in a ".cold" subfunction in .text.unlikely, objtool doesn't detect it, and instead prints a false warning: drivers/media/v4l2-core/v4l2-ioctl.o: warning: objtool: v4l_print_format.cold()+0xd6: sibling call from callable instruction with modified stack frame drivers/hwmon/max6650.o: warning: objtool: max6650_probe.cold()+0xa5: sibling call from callable instruction with modified stack frame drivers/media/dvb-frontends/drxk_hard.o: warning: objtool: init_drxk.cold()+0x16f: sibling call from callable instruction with modified stack frame Fix it by comparing the function, instead of the section and offset. Fixes: 13810435 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/157c35d42ca9b6354bbb1604fe9ad7d1153ccb21.1585761021.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
When compiling the kernel with AS=clang, objtool produces a lot of warnings: warning: objtool: missing symbol for section .text warning: objtool: missing symbol for section .init.text warning: objtool: missing symbol for section .ref.text It then fails to generate the ORC table. The problem is that objtool assumes text section symbols always exist. But the Clang assembler is aggressive about removing them. When generating relocations for the ORC table, objtool always tries to reference instructions by their section symbol offset. If the section symbol doesn't exist, it bails. Do a fallback: when a section symbol isn't available, reference a function symbol instead. Reported-by: NDmitry Golovin <dima@golovin.in> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NNathan Chancellor <natechancellor@gmail.com> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://github.com/ClangBuiltLinux/linux/issues/669 Link: https://lkml.kernel.org/r/9a9cae7fcf628843aabe5a086b1a3c5bf50f42e8.1585761021.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
Historically, the relocation symbols for ORC entries have only been section symbols: .text+0: sp:sp+8 bp:(und) type:call end:0 However, the Clang assembler is aggressive about stripping section symbols. In that case we will need to use function symbols: freezing_slow_path+0: sp:sp+8 bp:(und) type:call end:0 In preparation for the generation of such entries in "objtool orc generate", add support for reading them in "objtool orc dump". Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/b811b5eb1a42602c3b523576dc5efab9ad1c174d.1585761021.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
CONFIG_UBSAN_TRAP causes GCC to emit a UD2 whenever it encounters an unreachable code path. This includes __builtin_unreachable(). Because the BUG() macro uses __builtin_unreachable() after it emits its own UD2, this results in a double UD2. In this case objtool rightfully detects that the second UD2 is unreachable: init/main.o: warning: objtool: repair_env_string()+0x1c8: unreachable instruction We weren't able to figure out a way to get rid of the double UD2s, so just silence the warning. Reported-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NKees Cook <keescook@chromium.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/6653ad73c6b59c049211bd7c11ed3809c20ee9f5.1585761021.git.jpoimboe@redhat.com
-
- 09 4月, 2020 1 次提交
-
-
由 Masahiro Yamada 提交于
As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: NNick Desaulniers <ndesaulniers@google.com> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
-
- 28 3月, 2020 1 次提交
-
-
由 Al Viro 提交于
it's not really different from e.g. __sanitizer_cov_trace_cmp4(); as it is, the switches that generate an array of labels get rejected by objtool, while slightly different set of cases that gets compiled into a series of comparisons is accepted. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 26 3月, 2020 15 次提交
-
-
由 Peter Zijlstra 提交于
In preparation to adding a vmlinux.o specific pass, rearrange some code. No functional changes intended. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.924304616@infradead.org
-
由 Peter Zijlstra 提交于
Perf shows there is significant time in find_rela_by_dest(); this is because we have to iterate the address space per byte, looking for relocation entries. Optimize this by reducing the address space granularity. This reduces objtool on vmlinux.o runtime from 4.8 to 4.4 seconds. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.861321325@infradead.org
-
由 Peter Zijlstra 提交于
Perf shows we spend a measurable amount of time spend cleaning up right before we exit anyway. Avoid the needsless work and just terminate. This reduces objtool on vmlinux.o runtime from 5.4s to 4.8s Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.800720170@infradead.org
-
由 Peter Zijlstra 提交于
Perf showed that __hash_init() is a significant portion of read_sections(), so instead of doing a per section rela_hash, use an elf-wide rela_hash. Statistics show us there are about 1.1 million relas, so size it accordingly. This reduces the objtool on vmlinux.o runtime to a third, from 15 to 5 seconds. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.739153726@infradead.org
-
由 Peter Zijlstra 提交于
Perf showed that find_symbol_by_name() takes time; add a symbol name hash. This shaves another second off of objtool on vmlinux.o runtime, down to 15 seconds. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.676865656@infradead.org
-
由 Peter Zijlstra 提交于
Perf shows we're spending a lot of time in find_insn() and the statistics show we have around 3.2 million instruction. Increase the hash table size to reduce the bucket load from around 50 to 3. This shaves about 2s off of objtool on vmlinux.o runtime, down to 16s. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.617882545@infradead.org
-
由 Peter Zijlstra 提交于
For consistency; we have: find_symbol_by_offset() / find_symbol_containing() find_func_by_offset() / find_containing_func() fix that. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.558470724@infradead.org
-
由 Peter Zijlstra 提交于
All of: read_symbols(), find_symbol_by_offset(), find_symbol_containing(), find_containing_func() do a linear search of the symbols. Add an RB tree to make it go faster. This about halves objtool runtime on vmlinux.o, from 34s to 18s. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.499016559@infradead.org
-
由 Peter Zijlstra 提交于
In order to avoid yet another linear search of (20k) sections, add a name based hash. This reduces objtool runtime on vmlinux.o by some 10s to around 35s. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.440174280@infradead.org
-
由 Peter Zijlstra 提交于
In order to avoid a linear search (over 20k entries), add an section_hash to the elf object. This reduces objtool on vmlinux.o from a few minutes to around 45 seconds. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.381249993@infradead.org
-
由 Peter Zijlstra 提交于
Have it print a few numbers which can be used to size the hashtables. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.321381240@infradead.org
-
由 Peter Zijlstra 提交于
The symbol index is object wide, not per section, so it makes no sense to have the symbol_hash be part of the section object. By moving it to the elf object we avoid the linear sections iteration. This reduces the runtime of objtool on vmlinux.o from over 3 hours (I gave up) to a few minutes. The defconfig vmlinux.o has around 20k sections. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.261852348@infradead.org
-
由 Peter Zijlstra 提交于
Now that func_for_each_insn() is available, rename func_for_each_insn_all(). This gets us: sym_for_each_insn() - iterate on symbol offset/len func_for_each_insn() - iterate on insn->func Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.083720147@infradead.org
-
由 Peter Zijlstra 提交于
There is func_for_each_insn() and func_for_each_insn_all(), the both iterate the instructions, but the first uses symbol offset/length while the second uses insn->func. Rename func_for_each_insn() to sym_for_eac_insn() because it iterates on symbol information. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160924.024341229@infradead.org
-
由 Peter Zijlstra 提交于
Trivial 'cleanup' to save one indentation level and match validate_call(). Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200324160923.963996225@infradead.org
-
- 25 3月, 2020 1 次提交
-
-
由 Masahiro Yamada 提交于
Add SPDX License Identifier to all .gitignore files. Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 2月, 2020 2 次提交
-
-
由 Josh Poimboeuf 提交于
A recent clang change, combined with a binutils bug, can trigger a situation where a ".Lprintk$local" STT_NOTYPE symbol gets created at the same offset as the "printk" STT_FUNC symbol. This confuses objtool: kernel/printk/printk.o: warning: objtool: ignore_loglevel_setup()+0x10: can't find call dest symbol at .text+0xc67 Improve the call destination detection by looking specifically for an STT_FUNC symbol. Reported-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NNick Desaulniers <ndesaulniers@google.com> Tested-by: NNathan Chancellor <natechancellor@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/872 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25551 Link: https://lkml.kernel.org/r/0a7ee320bc0ea4469bd3dc450a7b4725669e0ea9.1581997059.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
Clang has the ability to create a switch table which is not a jump table, but is rather a table of string pointers. This confuses objtool, because it sees the relocations for the string pointers and assumes they're part of a jump table: drivers/ata/sata_dwc_460ex.o: warning: objtool: sata_dwc_bmdma_start_by_tag()+0x3a2: can't find switch jump table net/ceph/messenger.o: warning: objtool: ceph_con_workfn()+0x47c: can't find switch jump table Make objtool's find_jump_table() smart enough to distinguish between a switch jump table (which has relocations to text addresses in the same function as the original instruction) and other anonymous rodata (which may have relocations to elsewhere). Reported-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NNick Desaulniers <ndesaulniers@google.com> Tested-by: NNathan Chancellor <natechancellor@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/485 Link: https://lkml.kernel.org/r/263f6aae46d33da0b86d7030ced878cb5cab1788.1581997059.git.jpoimboe@redhat.com
-
- 11 2月, 2020 3 次提交
-
-
由 Josh Poimboeuf 提交于
Relocations in alternative code can be dangerous, because the code is copy/pasted to the text section after relocations have been resolved, which can corrupt PC-relative addresses. However, relocations might be acceptable in some cases, depending on the architecture. For example, the x86 alternatives code manually fixes up the target addresses for PC-relative jumps and calls. So disallow relocations in alternative code, except where the x86 arch code allows it. This code may need to be tweaked for other arches when objtool gets support for them. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NJulien Thierry <jthierry@redhat.com> Link: https://lkml.kernel.org/r/7b90b68d093311e4e8f6b504a9e1c758fd7e0002.1581359535.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
There are several places where objtool tests for a non-dynamic (aka direct) jump. Move the check to a helper function. Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NJulien Thierry <jthierry@redhat.com> Link: https://lkml.kernel.org/r/9b8b438df918276315e4765c60d2587f3c7ad698.1581359535.git.jpoimboe@redhat.com
-
由 Josh Poimboeuf 提交于
When objtool encounters a fatal error, it usually means the binary is corrupt or otherwise broken in some way. Up until now, such errors were just treated as warnings which didn't fail the kernel build. However, objtool is now stable enough that if a fatal error is discovered, it most likely means something is seriously wrong and it should fail the kernel build. Note that this doesn't apply to "normal" objtool warnings; only fatal ones. Suggested-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NJulien Thierry <jthierry@redhat.com> Link: https://lkml.kernel.org/r/f18c3743de0fef673d49dd35760f26bdef7f6fc3.1581359535.git.jpoimboe@redhat.com
-
- 22 1月, 2020 2 次提交
-
-
由 Shile Zhang 提交于
Building objtool with ARCH=x86_64 fails with: $make ARCH=x86_64 -C tools/objtool ... CC arch/x86/decode.o arch/x86/decode.c:10:22: fatal error: asm/insn.h: No such file or directory #include <asm/insn.h> ^ compilation terminated. mv: cannot stat ‘arch/x86/.decode.o.tmp’: No such file or directory make[2]: *** [arch/x86/decode.o] Error 1 ... The root cause is that the command-line variable 'ARCH' cannot be overridden. It can be replaced by 'SRCARCH', which is defined in 'tools/scripts/Makefile.arch'. Signed-off-by: NShile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Reviewed-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/d5d11370ae116df6c653493acd300ec3d7f5e925.1579543924.git.jpoimboe@redhat.com
-
由 Olof Johansson 提交于
The sync-check.sh script prints out the path due to a "cd -" at the end of the script, even on silent builds. This isn't even needed, since the script is executed in our build instead of sourced (so it won't change the working directory of the surrounding build anyway). Just remove the cd to make the build silent. Fixes: 2ffd84ae ("objtool: Update sync-check.sh from perf's check-headers.sh") Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/cb002857fafa8186cfb9c3e43fb62e4108a1bab9.1579543924.git.jpoimboe@redhat.com
-
- 28 10月, 2019 1 次提交
-
-
由 Peter Zijlstra 提交于
The new check_zeroed_user() function uses variable shifts inside of a user_access_begin()/user_access_end() section and that results in GCC emitting __ubsan_handle_shift_out_of_bounds() calls, even though through value range analysis it would be able to see that the UB in question is impossible. Annotate and whitelist this UBSAN function; continued use of user_access_begin()/user_access_end() will undoubtedly result in further uses of function. Reported-by: NRandy Dunlap <rdunlap@infradead.org> Tested-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NRandy Dunlap <rdunlap@infradead.org> Acked-by: NChristian Brauner <christian.brauner@ubuntu.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: cyphar@cyphar.com Cc: keescook@chromium.org Cc: linux@rasmusvillemoes.dk Fixes: f5a1a536 ("lib: introduce copy_struct_from_user() helper") Link: https://lkml.kernel.org/r/20191021131149.GA19358@hirez.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 18 10月, 2019 1 次提交
-
-
由 Masami Hiramatsu 提交于
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder. It is called "prefix" but actually not x86 instruction prefix, so this adds insn.emulate_prefix_size field instead of reusing insn.prefixes. If x86 decoder finds a special sequence of instructions of XEN_EMULATE_PREFIX and 'ud2a; .ascii "kvm"', it just counts the length, set insn.emulate_prefix_size and fold it with the next instruction. In other words, the signature and the next instruction is treated as a single instruction. Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: x86@kernel.org Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Borislav Petkov <bp@alien8.de> Cc: xen-devel@lists.xenproject.org Cc: Randy Dunlap <rdunlap@infradead.org> Link: https://lkml.kernel.org/r/156777564986.25081.4964537658500952557.stgit@devnote2
-
- 01 10月, 2019 1 次提交
-
-
由 Brendan Higgins 提交于
Fix the following warning seen on GCC 7.3: kunit/test-test.o: warning: objtool: kunit_test_unsuccessful_try() falls through to next function kunit_test_catch() kunit_try_catch_throw is a function added in the following patch in this series; it allows KUnit, a unit testing framework for the kernel, to bail out of a broken test. As a consequence, it is a new __noreturn function that objtool thinks is broken (as seen above). So fix this warning by adding kunit_try_catch_throw to objtool's noreturn list. Reported-by: Nkbuild test robot <lkp@intel.com> Signed-off-by: NBrendan Higgins <brendanhiggins@google.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://www.spinics.net/lists/linux-kbuild/msg21708.html Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
-
- 25 9月, 2019 1 次提交
-
-
由 Sean Christopherson 提交于
Explicitly check kvm_rebooting in kvm_spurious_fault() prior to invoking BUG(), as opposed to assuming the caller has already done so. Letting kvm_spurious_fault() be called "directly" will allow VMX to better optimize its low level assembly flows. As a happy side effect, kvm_spurious_fault() no longer needs to be marked as a dead end since it doesn't unconditionally BUG(). Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 10 9月, 2019 1 次提交
-
-
由 Josh Poimboeuf 提交于
If the build user has the CFLAGS variable set in their environment, objtool blindly appends to it, which can cause unexpected behavior. Clobber CFLAGS to ensure consistent objtool compilation behavior. Reported-by: NValdis Kletnieks <valdis.kletnieks@vt.edu> Tested-by: NValdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 01 9月, 2019 3 次提交
-
-
由 Arnaldo Carvalho de Melo 提交于
Since we need to build this in !x86, we need to explicitely use the x86 files, not things like asm/insn.h, so we intentionally differ from the master copy in the kernel sources, add -I diff directives to ignore just these differences when checking for drift. Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: http://lore.kernel.org/lkml/20190830193109.p7jagidsrahoa4pn@trebleAcked-by: NMasami Hiramatsu <mhiramat@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/n/tip-j965m9b7xtdc83em3twfkh9o@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Arnaldo Carvalho de Melo 提交于
To allow using the -I trick that will be needed for checking the x86 insn decoder files. Without the specific -I lines we still get the same warnings as before: $ make -C tools/objtool/ clean ; make -C tools/objtool/ make: Entering directory '/home/acme/git/perf/tools/objtool' CLEAN objtool find -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete rm -f arch/x86/inat-tables.c fixdep <SNIP> LD objtool-in.o make[1]: Leaving directory '/home/acme/git/perf/tools/objtool' Warning: Kernel ABI header at 'tools/arch/x86/include/asm/inat.h' differs from latest version at 'arch/x86/include/asm/inat.h' diff -u tools/arch/x86/include/asm/inat.h arch/x86/include/asm/inat.h Warning: Kernel ABI header at 'tools/arch/x86/include/asm/insn.h' differs from latest version at 'arch/x86/include/asm/insn.h' diff -u tools/arch/x86/include/asm/insn.h arch/x86/include/asm/insn.h Warning: Kernel ABI header at 'tools/arch/x86/lib/inat.c' differs from latest version at 'arch/x86/lib/inat.c' diff -u tools/arch/x86/lib/inat.c arch/x86/lib/inat.c Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs from latest version at 'arch/x86/lib/insn.c' diff -u tools/arch/x86/lib/insn.c arch/x86/lib/insn.c /home/acme/git/perf/tools/objtool LINK objtool make: Leaving directory '/home/acme/git/perf/tools/objtool' $ The next patch will add the -I lines for those files. Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: http://lore.kernel.org/lkml/20190830193109.p7jagidsrahoa4pn@trebleAcked-by: NMasami Hiramatsu <mhiramat@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/n/tip-vu3p38mnxlwd80rlsnjkqcf2@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
由 Josh Poimboeuf 提交于
The kernel tree has three identical copies of the x86 instruction decoder. Two of them are in the tools subdir. The tools subdir is supposed to be completely standalone and separate from the kernel. So having at least one copy of the kernel decoder in the tools subdir is unavoidable. However, we don't need *two* of them. Move objtool's copy of the decoder to a shared location, so that perf will also be able to use it. Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: x86@kernel.org Link: http://lore.kernel.org/lkml/55b486b88f6bcd0c9a2a04b34f964860c8390ca8.1567118001.git.jpoimboe@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-