- 01 5月, 2020 3 次提交
-
-
由 Peter Zijlstra 提交于
Jann reported that (for instance) entry_64.o:general_protection has very odd ORC data: 0000000000000f40 <general_protection>: #######sp:sp+8 bp:(und) type:iret end:0 f40: 90 nop #######sp:(und) bp:(und) type:call end:0 f41: 90 nop f42: 90 nop #######sp:sp+8 bp:(und) type:iret end:0 f43: e8 a8 01 00 00 callq 10f0 <error_entry> #######sp:sp+0 bp:(und) type:regs end:0 f48: f6 84 24 88 00 00 00 testb $0x3,0x88(%rsp) f4f: 03 f50: 74 00 je f52 <general_protection+0x12> f52: 48 89 e7 mov %rsp,%rdi f55: 48 8b 74 24 78 mov 0x78(%rsp),%rsi f5a: 48 c7 44 24 78 ff ff movq $0xffffffffffffffff,0x78(%rsp) f61: ff ff f63: e8 00 00 00 00 callq f68 <general_protection+0x28> f68: e9 73 02 00 00 jmpq 11e0 <error_exit> #######sp:(und) bp:(und) type:call end:0 f6d: 0f 1f 00 nopl (%rax) Note the entry at 0xf41. Josh found this was the result of commit: 764eef4b ("objtool: Rewrite alt->skip_orig") Due to the early return in validate_branch() we no longer set insn->cfi of the original instruction stream (the NOPs at 0xf41 and 0xf42) and we'll end up with the above weirdness. In other discussions we realized alternatives should be ORC invariant; that is, due to there being only a single ORC table, it must be valid for all alternatives. The easiest way to ensure this is to not allow any stack modifications in alternatives. When we enforce this latter observation, we get the property that the whole alternative must have the same CFI, which we can employ to fix the former report. Fixes: 764eef4b ("objtool: Rewrite alt->skip_orig") Reported-by: NJann Horn <jannh@google.com> 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/20200428191659.499074346@infradead.org
-
由 Alexandre Chartre 提交于
Assign a unique identifier to every alternative instruction group in order to be able to tell which instructions belong to what alternative. [peterz: extracted from a larger patch] Signed-off-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz>
-
由 Julien Thierry 提交于
While jumping from outside an alternative region to the middle of an alternative region is very likely wrong, jumping from an alternative region into the same region is valid. It is a common pattern on arm64. The first pattern is unlikely to happen in practice and checking only for this adds a lot of complexity. Just remove the current check. Suggested-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NJulien Thierry <jthierry@redhat.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Link: https://lkml.kernel.org/r/20200327152847.15294-6-jthierry@redhat.com
-
- 23 4月, 2020 3 次提交
-
-
由 Ingo Molnar 提交于
Mostly straightforward constification, except that WARN_FUNC() needs a writable pointer while we have read-only pointers, so deflect this to WARN(). Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200422103205.61900-4-mingo@kernel.org
-
由 Ingo Molnar 提交于
'struct elf *' handling is an open/close paradigm, make sure the naming matches that: elf_open_read() elf_write() elf_close() Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200422103205.61900-3-mingo@kernel.org
-
由 Ingo Molnar 提交于
In preparation to parallelize certain parts of objtool, map out which uses of various data structures are read-only vs. read-write. As a first step constify 'struct elf' pointer passing, most of the secondary uses of it in find_symbol_*() methods are read-only. Also, while at it, better group the 'struct elf' handling methods in elf.h. Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200422103205.61900-2-mingo@kernel.org
-
- 22 4月, 2020 26 次提交
-
-
由 Thomas Gleixner 提交于
Consider all of .entry.text as noinstr. This gets us coverage across the PTI boundary. While we could add everything .noinstr.text into .entry.text that would bloat the amount of code in the user mapping. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.525037514@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Make sure to also check STT_NOTYPE symbols for noinstr violations. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.465335884@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
In preparation of further changes, once again break out the loop body. No functional changes intended. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.405863817@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
validate_functions() iterates all sections their symbols; this is pointless to do for !text sections as they won't have instructions anyway. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.346582716@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
In preparation for find_insn_containing(), change insn_hash to use sec_offset_hash(). This actually reduces runtime; probably because mixing in the section index reduces the collisions due to text sections all starting their instructions at offset 0. Runtime on vmlinux.o from 3.1 to 2.5 seconds. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.227240432@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
When doing kbuild tests to see if the objtool changes affected those I found that there was a measurable regression: pre post real 1m13.594 1m16.488s user 34m58.246s 35m23.947s sys 4m0.393s 4m27.312s Perf showed that for small files the increased hash-table sizes were a measurable difference. Since we already have -l "vmlinux" to distinguish between the modes, make it also use a smaller portion of the hash-tables. This flips it into a small win: real 1m14.143s user 34m49.292s sys 3m44.746s Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.167588731@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Validate that any call out of .noinstr.text is in between instr_begin() and instr_end() annotations. This annotation is useful to ensure correct behaviour wrt tracing sensitive code like entry/exit and idle code. When we run code in a sensitive context we want a guarantee no unknown code is ran. Since this validation relies on knowing the section of call destination symbols, we must run it on vmlinux.o instead of on individual object files. Add two options: -d/--duplicate "duplicate validation for vmlinux" -l/--vmlinux "vmlinux.o validation" Where the latter auto-detects when objname ends with "vmlinux.o" and the former will force all validations, also those already done on !vmlinux object files. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.106268040@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Objtool keeps per instruction CFI state in struct insn_state and will save/restore this where required. However, insn_state has grown some !CFI state, and this must not be saved/restored (that would loose/destroy state). Fix this by moving the CFI specific parts of insn_state into struct cfi_state. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115119.045821071@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
There's going to be a new struct cfi_state, rename this one to make place. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115118.986441913@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
The SAVE/RESTORE hints are now unused; remove them. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115118.926738768@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Normally objtool ensures a function keeps the stack layout invariant. But there is a useful exception, it is possible to stuff the return stack in order to 'inject' a 'call': push $fun ret In this case the invariant mentioned above is violated. Add an objtool HINT to annotate this and allow a function exit with a modified stack frame. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115118.690601403@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Teach objtool a little more about IRET so that we can avoid using the SAVE/RESTORE annotation. In particular, make the weird corner case in insn->restore go away. The purpose of that corner case is to deal with the fact that UNWIND_HINT_RESTORE lands on the instruction after IRET, but that instruction can end up being outside the basic block, consider: if (cond) sync_core() foo(); Then the hint will land on foo(), and we'll encounter the restore hint without ever having seen the save hint. By teaching objtool about the arch specific exception frame size, and assuming that any IRET in an STT_FUNC symbol is an exception frame sized POP, we can remove the use of save/restore hints for this code. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200416115118.631224674@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
Instruction sets can include more or less complex operations which might not fit the currently defined set of stack_ops. Combining more than one stack_op provides more flexibility to describe the behaviour of an instruction. This also reduces the need to define new stack_ops specific to a single instruction set. Allow instruction decoders to generate multiple stack_op per instruction. Signed-off-by: NJulien Thierry <jthierry@redhat.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20200327152847.15294-11-jthierry@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Muchun Song 提交于
If the prefix of section name is not '.rodata', the following function call can never return 0. strcmp(sec->name, C_JUMP_TABLE_SECTION) So the name comparison is pointless, just remove it. Signed-off-by: NMuchun Song <songmuchun@bytedance.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Nick Desaulniers 提交于
Compiling with Clang and CONFIG_KASAN=y was exposing a few warnings: call to memset() with UACCESS enabled Document how to fix these for future travelers. Link: https://github.com/ClangBuiltLinux/linux/issues/876Suggested-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com> Suggested-by: NMatt Helsley <mhelsley@vmware.com> Suggested-by: NPeter Zijlstra <peterz@infradead.org> Suggested-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
Some CFI definitions used by generic objtool code have no reason to vary from one architecture to another. Keep those definitions in generic code and move the arch-specific ones to a new arch-specific header. Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Raphael Gault 提交于
The jump and call destination relocation offsets are x86-specific. Abstract them by calling arch-specific implementations. [ jthierry: Remove superfluous comment; replace other addend offsets with arch_dest_rela_offset() ] Signed-off-by: NRaphael Gault <raphael.gault@arm.com> Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
The initial register state is set up by arch specific code. Use the value the arch code has set when restoring registers from the stack. Suggested-by: NRaphael Gault <raphael.gault@arm.com> Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
The .alternatives section can contain entries with no original instructions. Objtool will currently crash when handling such an entry. Just skip that entry, but still give a warning to discourage useless entries. Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
When a function fails its validation, it might leave a stale state that will be used for the validation of other functions. That would cause false warnings on potentially valid functions. Reset the instruction state before the validation of each individual function. Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
POP operations are already in the code path where the destination operand is OP_DEST_REG. There is no need to check the operand type again. Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Julien Thierry 提交于
Currently, the check of tools files against kernel equivalent is only done after every object file has been built. This means one might fix build issues against outdated headers without seeing a warning about this. Check headers before any object is built. Also, make it part of a FORCE'd recipe so every attempt to build objtool will report the outdated headers (if any). Signed-off-by: NJulien Thierry <jthierry@redhat.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NMiroslav Benes <mbenes@suse.cz> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 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> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 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> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Lucas Stach 提交于
Commit 7ed1c190 ("tools: fix cross-compile var clobbering") moved the setup of the CC variable to tools/scripts/Makefile.include to make the behavior consistent across all the tools Makefiles. As the vm tools missed the include we end up with the wrong CC in a cross-compiling evironment. Fixes: 7ed1c190 (tools: fix cross-compile var clobbering) Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Martin Kelly <martin@martingkelly.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200416104748.25243-1-l.stach@pengutronix.deSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 George Burgess IV 提交于
Clang has -Wself-assign enabled by default under -Wall, which always gets -Werror'ed on this file, causing sync-compare-and-swap to be disabled by default. The generally-accepted way to spell "this value is intentionally unused," is casting it to `void`. This is accepted by both GCC and Clang with -Wall enabled: https://godbolt.org/z/qqZ9r3Signed-off-by: NGeorge Burgess IV <gbiv@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Link: http://lkml.kernel.org/r/20200414195638.156123-1-gbiv@google.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 4月, 2020 3 次提交
-
-
由 Michael S. Tsirkin 提交于
We are using abort() so let's include stdlib.h Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Michael S. Tsirkin 提交于
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Michael S. Tsirkin 提交于
Allow building vringh without IOTLB (that's the case for userspace builds, will be useful for CAIF/VOD down the road too). Update for API tweaks. Don't include vringh with userspace builds. Cc: Jason Wang <jasowang@redhat.com> Cc: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NJason Wang <jasowang@redhat.com>
-
- 15 4月, 2020 5 次提交
-
-
由 Toke Høiland-Jørgensen 提交于
David Ahern noticed that there was a bug in the EXPECTED_FD code so programs did not get detached properly when that parameter was supplied. This case was not included in the xdp_attach tests; so let's add it to be sure that such a bug does not sneak back in down. Fixes: 87854a0b ("selftests/bpf: Add tests for attaching XDP programs") Reported-by: NDavid Ahern <dsahern@gmail.com> Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20200414145025.182163-2-toke@redhat.com
-
由 Toke Høiland-Jørgensen 提交于
The 'old_fd' parameter used for atomic replacement of XDP programs is supposed to be an FD, but was left as a u32 from an earlier iteration of the patch that added it. It was converted to an int when read, so things worked correctly even with negative values, but better change the definition to correctly reflect the intention. Fixes: bd5ca3ef ("libbpf: Add function to set link XDP fd while specifying old program") Reported-by: NDavid Ahern <dsahern@gmail.com> Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NDavid Ahern <dsahern@gmail.com> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20200414145025.182163-1-toke@redhat.com
-
由 Andrii Nakryiko 提交于
For some types of BPF programs that utilize expected_attach_type, libbpf won't set load_attr.expected_attach_type, even if expected_attach_type is known from section definition. This was done to preserve backwards compatibility with old kernels that didn't recognize expected_attach_type attribute yet (which was added in 5e43f899 ("bpf: Check attach type at prog load time"). But this is problematic for some BPF programs that utilize newer features that require kernel to know specific expected_attach_type (e.g., extended set of return codes for cgroup_skb/egress programs). This patch makes libbpf specify expected_attach_type by default, but also detect support for this field in kernel and not set it during program load. This allows to have a good metadata for bpf_program (e.g., bpf_program__get_extected_attach_type()), but still work with old kernels (for cases where it can work at all). Additionally, due to expected_attach_type being always set for recognized program types, bpf_program__attach_cgroup doesn't have to do extra checks to determine correct attach type, so remove that additional logic. Also adjust section_names selftest to account for this change. More detailed discussion can be found in [0]. [0] https://lore.kernel.org/bpf/20200412003604.GA15986@rdna-mbp.dhcp.thefacebook.com/ Fixes: 5cf1e914 ("bpf: cgroup inet skb programs can return 0 to 3") Fixes: 5e43f899 ("bpf: Check attach type at prog load time") Reported-by: NAndrey Ignatov <rdna@fb.com> Signed-off-by: NAndrii Nakryiko <andriin@fb.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NSong Liu <songliubraving@fb.com> Acked-by: NAndrey Ignatov <rdna@fb.com> Link: https://lore.kernel.org/bpf/20200414182645.1368174-1-andriin@fb.com
-
由 Daniel T. Lee 提交于
In commit 65c93628 ("bpftool: Add struct_ops support") a new type of command named struct_ops has been added. This command requires a kernel with CONFIG_DEBUG_INFO_BTF=y set and for retrieving BTF info in bpftool, the helper get_btf_vmlinux() is used. When running this command on kernel without BTF debug info, this will lead to 'btf_vmlinux' variable being an invalid(error) pointer. And by this, btf_free() causes a segfault when executing 'bpftool struct_ops'. This commit adds pointer validation with IS_ERR not to free invalid pointer, and this will fix the segfault issue. Fixes: 65c93628 ("bpftool: Add struct_ops support") Signed-off-by: NDaniel T. Lee <danieltimlee@gmail.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NMartin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200410020612.2930667-1-danieltimlee@gmail.com
-
由 Andrii Nakryiko 提交于
Test that frozen and mmap()'ed BPF map can't be mprotect()'ed as writable or executable memory. Also validate that "downgrading" from writable to read-only doesn't screw up internal writable count accounting for the purposes of map freezing. Signed-off-by: NAndrii Nakryiko <andriin@fb.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200410202613.3679837-2-andriin@fb.com
-