- 23 Apr, 2021 19 commits
-
-
Andrii Nakryiko authored
Add selftest validating various aspects of statically linking functions: - no conflicts and correct resolution for name-conflicting static funcs; - correct resolution of extern functions; - correct handling of weak functions, both resolution itself and libbpf's handling of unused weak function that "lost" (it leaves gaps in code with no ELF symbols); - correct handling of hidden visibility to turn global function into "static" for the purpose of BPF verification. Signed-off-by:Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210423181348.1801389-16-andrii@kernel.org
-
Andrii Nakryiko authored
Skip generating individual BPF skeletons for files that are supposed to be linked together to form the final BPF object file. Very often such files are "incomplete" BPF object files, which will fail libbpf bpf_object__open() step, if used individually, thus failing BPF skeleton generation. This is by design, so skip individual BPF skeletons and only validate them as part of their linked final BPF object file and skeleton. Signed-off-by:
-
Andrii Nakryiko authored
While -Og is designed to work well with debugger, it's still inferior to -O0 in terms of debuggability experience. It will cause some variables to still be inlined, it will also prevent single-stepping some statements and otherwise interfere with debugging experience. So switch to -O0 which turns off any optimization and provides the best debugging experience. Signed-off-by:
-
Andrii Nakryiko authored
Add extra logic to handle map externs (only BTF-defined maps are supported for linking). Re-use the map parsing logic used during bpf_object__open(). Map externs are currently restricted to always match complete map definition. So all the specified attributes will be compared (down to pining, map_flags, numa_node, etc). In the future this restriction might be relaxed with no backwards compatibility issues. If any attribute is mismatched between extern and actual map definition, linker will report an error, pointing out which one mismatches. The original intent was to allow for extern to specify attributes that matters (to user) to enforce. E.g., if you specify just key information and omit value, then any value fits. Similarly, it should have been possible to enforce map_flags, pinning, and any other possible map attribute. Unfortunately, that means that multiple externs can be only partially overlapping with each other, which means linker would need to combine their type definitions to end up with the most restrictive and fullest map definition. This requires an extra amount of BTF manipulation which at this time was deemed unnecessary and would require further extending generic BTF writer APIs. So that is left for future follow ups, if there will be demand for that. But the idea seems intresting and useful, so I want to document it here. Weak definitions are also supported, but are pretty strict as well, just like externs: all weak map definitions have to match exactly. In the follow up patches this most probably will be relaxed, with __weak map definitions being able to differ between each other (with non-weak definition always winning, of course). Signed-off-by:
-
Andrii Nakryiko authored
Add BPF static linker logic to resolve extern variables and functions across multiple linked together BPF object files. For that, linker maintains a separate list of struct glob_sym structures, which keeps track of few pieces of metadata (is it extern or resolved global, is it a weak symbol, which ELF section it belongs to, etc) and ties together BTF type info and ELF symbol information and keeps them in sync. With adding support for extern variables/funcs, it's now possible for some sections to contain both extern and non-extern definitions. This means that some sections may start out as ephemeral (if only externs are present and thus there is not corresponding ELF section), but will be "upgraded" to actual ELF section as symbols are resolved or new non-extern definitions are appended. Additional care is taken to not duplicate extern entries in sections like .kconfig and .ksyms. Given libbpf requires BTF type to always be present for .kconfig/.ksym externs, linker extends this requirement to all the externs, even those that are supposed to be resolved during static linking and which won't be visible to libbpf. With BTF information always present, static linker will check not just ELF symbol matches, but entire BTF type signature match as well. That logic is stricter that BPF CO-RE checks. It probably should be re-used by .ksym resolution logic in libbpf as well, but that's left for follow up patches. To make it unnecessary to rewrite ELF symbols and minimize BTF type rewriting/removal, ELF symbols that correspond to externs initially will be updated in place once they are resolved. Similarly for BTF type info, VAR/FUNC and var_secinfo's (sec_vars in struct bpf_linker) are staying stable, but types they point to might get replaced when extern is resolved. This might leave some left-over types (even though we try to minimize this for common cases of having extern funcs with not argument names vs concrete function with names properly specified). That can be addresses later with a generic BTF garbage collection. That's left for a follow up as well. Given BTF type appending phase is separate from ELF symbol appending/resolution, special struct glob_sym->underlying_btf_id variable is used to communicate resolution and rewrite decisions. 0 means underlying_btf_id needs to be appended (it's not yet in final linker->btf), <0 values are used for temporary storage of source BTF type ID (not yet rewritten), so -glob_sym->underlying_btf_id is BTF type id in obj-btf. But by the end of linker_append_btf() phase, that underlying_btf_id will be remapped and will always be > 0. This is the uglies part of the whole process, but keeps the other parts much simpler due to stability of sec_var and VAR/FUNC types, as well as ELF symbol, so please keep that in mind while reviewing. BTF-defined maps require some extra custom logic and is addressed separate in the next patch, so that to keep this one smaller and easier to review. Signed-off-by:
-
Andrii Nakryiko authored
It should never fail, but if it does, it's better to know about this rather than end up with nonsensical type IDs. Signed-off-by:
-
Andrii Nakryiko authored
Add logic to validate extern symbols, plus some other minor extra checks, like ELF symbol #0 validation, general symbol visibility and binding validations. Signed-off-by:
-
Andrii Nakryiko authored
Make skip_mods_and_typedefs(), btf_kind_str(), and btf_func_linkage() helpers available outside of libbpf.c, to be used by static linker code. Also do few cleanups (error code fixes, comment clean up, etc) that don't deserve their own commit. Signed-off-by:
-
Andrii Nakryiko authored
Factor out logic for sanity checking SHT_SYMTAB and SHT_REL sections into separate sections. They are already quite extensive and are suffering from too deep indentation. Subsequent changes will extend SYMTAB sanity checking further, so it's better to factor each into a separate function. No functional changes are intended. Signed-off-by:
-
Andrii Nakryiko authored
Refactor BTF-defined maps parsing logic to allow it to be nicely reused by BPF static linker. Further, at least for BPF static linker, it's important to know which attributes of a BPF map were defined explicitly, so provide a bit set for each known portion of BTF map definition. This allows BPF static linker to do a simple check when dealing with extern map declarations. The same capabilities allow to distinguish attributes explicitly set to zero (e.g., __uint(max_entries, 0)) vs the case of not specifying it at all (no max_entries attribute at all). Libbpf is currently not utilizing that, but it could be useful for backwards compatibility reasons later. Signed-off-by:
-
Andrii Nakryiko authored
Currently libbpf is very strict about parsing BPF program instruction sections. No gaps are allowed between sequential BPF programs within a given ELF section. Libbpf enforced that by keeping track of the next section offset that should start a new BPF (sub)program and cross-checks that by searching for a corresponding STT_FUNC ELF symbol. But this is too restrictive once we allow to have weak BPF programs and link together two or more BPF object files. In such case, some weak BPF programs might be "overridden" by either non-weak BPF program with the same name and signature, or even by another weak BPF program that just happened to be linked first. That, in turn, leaves BPF instructions of the "lost" BPF (sub)program intact, but there is no corresponding ELF symbol, because no one is going to be referencing it. Libbpf already correctly handles such cases in the sense that it won't append such dead code to actual BPF programs loaded into kernel. So the only change that needs to be done is to relax the logic of parsing BPF instruction sections. Instead of assuming next BPF (sub)program section offset, iterate available STT_FUNC ELF symbols to discover all available BPF subprograms and programs. Signed-off-by:
-
Andrii Nakryiko authored
Define __hidden helper macro in bpf_helpers.h, which is a short-hand for __attribute__((visibility("hidden"))). Add libbpf support to mark BPF subprograms marked with __hidden as static in BTF information to enforce BPF verifier's static function validation algorithm, which takes more information (caller's context) into account during a subprogram validation. Signed-off-by: -
Andrii Nakryiko authored
When used on externs SEC() macro will trigger compilation warning about inapplicable `__attribute__((used))`. That's expected for extern declarations, so suppress it with the corresponding _Pragma. Signed-off-by:
-
Andrii Nakryiko authored
Dump succinct information for each member of DATASEC: its kinds and name. This is extremely helpful to see at a quick glance what is inside each DATASEC of a given BTF. Without this, one has to jump around BTF data to just find out the name of a VAR or FUNC. DATASEC's var_secinfo member is special in that regard because it doesn't itself contain the name of the member, delegating that to the referenced VAR and FUNC kinds. Other kinds, like STRUCT/UNION/FUNC/ENUM, encode member names directly and thus are clearly identifiable in BTF dump. The new output looks like this: [35] DATASEC '.bss' size=0 vlen=6 type_id=8 offset=0 size=4 (VAR 'input_bss1') type_id=13 offset=0 size=4 (VAR 'input_bss_weak') type_id=16 offset=0 size=4 (VAR 'output_bss1') type_id=17 offset=0 size=4 (VAR 'output_data1') type_id=18 offset=0 size=4 (VAR 'output_rodata1') type_id=20 offset=0 size=8 (VAR 'output_sink1') [36] DATASEC '.data' size=0 vlen=2 type_id=9 offset=0 size=4 (VAR 'input_data1') type_id=14 offset=0 size=4 (VAR 'input_data_weak') [37] DATASEC '.kconfig' size=0 vlen=2 type_id=25 offset=0 size=4 (VAR 'LINUX_KERNEL_VERSION') type_id=28 offset=0 size=1 (VAR 'CONFIG_BPF_SYSCALL') [38] DATASEC '.ksyms' size=0 vlen=1 type_id=30 offset=0 size=1 (VAR 'bpf_link_fops') [39] DATASEC '.rodata' size=0 vlen=2 type_id=12 offset=0 size=4 (VAR 'input_rodata1') type_id=15 offset=0 size=4 (VAR 'input_rodata_weak') [40] DATASEC 'license' size=0 vlen=1 type_id=24 offset=0 size=4 (VAR 'LICENSE') Signed-off-by: -
Andrii Nakryiko authored
Add dumping of "extern" linkage for BTF VAR kind. Also shorten "global-allocated" to "global" to be in line with FUNC's "global". Signed-off-by:
-
Alexei Starovoitov authored
Florent Revest says: ==================== Alexei requested a couple of cleanups to the bpf_snprintf and ARG_PTR_TO_CONST_STR verifier code. https://lore.kernel.org/bpf/CABRcYmL_SMT80UTyV98bRsOzW0wBd1sZcYUpTrcOAV+9m+YoWQ@mail.gmail.com/T/#t ==================== Signed-off-by:
-
Florent Revest authored
reg->type is enforced by check_reg_type() and map should never be NULL (it would already have been dereferenced anyway) so these checks are unnecessary. Reported-by:
Florent Revest <revest@chromium.org> Signed-off-by:
-
Florent Revest authored
In check_bpf_snprintf_call(), a map_direct_value_addr() of the fmt map should never fail because it has already been checked by ARG_PTR_TO_CONST_STR. But if it ever fails, it's better to error out with an explicit debug message rather than silently fail. Reported-by:
-
Li RongQing authored
DPDK default burst size is 32, however, kernel xsk sendto syscall can not handle all 32 at one time, and return with error. So make kernel XDP socket batch size larger to avoid unnecessary syscall fail and context switch which will help to increase performance. Signed-off-by:
Li RongQing <lirongqing@baidu.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/bpf/1618378752-4191-1-git-send-email-lirongqing@baidu.com
-
- 22 Apr, 2021 2 commits
-
-
Tiezhu Yang authored
There exist some errors "404 Not Found" when I click the link of "MAINTAINERS" [1], "samples/bpf/" [2] and "selftests" [3] in the documentation "HOWTO interact with BPF subsystem" [4]. As Alexei Starovoitov suggested, just remove "MAINTAINERS" and "samples/bpf/" links and use correct link of "selftests". [1] https://www.kernel.org/doc/html/MAINTAINERS [2] https://www.kernel.org/doc/html/samples/bpf/ [3] https://www.kernel.org/doc/html/tools/testing/selftests/bpf/ [4] https://www.kernel.org/doc/html/latest/bpf/bpf_devel_QA.html Fixes: 54222838 ("bpf, doc: convert bpf_devel_QA.rst to use RST formatting") Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/bpf/1619062560-30483-1-git-send-email-yangtiezhu@loongson.cn
-
Martin Willi authored
If a generic XDP program changes the destination MAC address from/to multicast/broadcast, the skb->pkt_type is updated to properly handle the packet when passed up the stack. When changing the MAC from/to the NICs MAC, PACKET_HOST/OTHERHOST is not updated, though, making the behavior different from that of native XDP. Remember the PACKET_HOST/OTHERHOST state before calling the program in generic XDP, and update pkt_type accordingly if the destination MAC address has changed. As eth_type_trans() assumes a default pkt_type of PACKET_HOST, restore that before calling it. The use case for this is when a XDP program wants to push received packets up the stack by rewriting the MAC to the NICs MAC, for example by cluster nodes sharing MAC addresses. Fixes: 29724956 ("net: fix generic XDP to handle if eth header was mangled") Signed-off-by:
Martin Willi <martin@strongswan.org> Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/bpf/20210419141559.8611-1-martin@strongswan.org
-
- 20 Apr, 2021 6 commits
-
-
Jiri Olsa authored
Currently docs target is make dependency for TEST_GEN_FILES, which makes tests to be rebuilt every time you run make. Adding docs as all target dependency, so when running make on top of built selftests it will show just: $ make make[1]: Nothing to be done for 'docs'. After cleaning docs, only docs is rebuilt: $ make docs-clean CLEAN eBPF_helpers-manpage CLEAN eBPF_syscall-manpage $ make GEN ...selftests/bpf/bpf-helpers.rst GEN ...selftests/bpf/bpf-helpers.7 GEN ...selftests/bpf/bpf-syscall.rst GEN ...selftests/bpf/bpf-syscall.2 $ make make[1]: Nothing to be done for 'docs'. Fixes: a01d935b ("tools/bpf: Remove bpf-helpers from bpftool docs") Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
-
Alexei Starovoitov authored
Dave Marchevsky says: ==================== Similarly to the bpf_get_stack helper, bpf_get_task_stack's return value can be more tightly bound by the verifier - it's the number of bytes written to a user-supplied buffer, or a negative error value. Currently the verifier believes bpf_task_get_stack's retval bounds to be unknown, requiring extraneous bounds checking to remedy. Adding it to do_refine_retval_range fixes the issue, as evidenced by new selftests which fail to load if retval bounds are not refined. v2: Addressed comment nit in patch 3 ==================== Signed-off-by: -
Dave Marchevsky authored
Add a libbpf test prog which feeds bpf_get_task_stack's return value into seq_write after confirming it's positive. No attempt to bound the value from above is made. Load will fail if verifier does not refine retval range based on buf sz input to bpf_get_task_stack. Signed-off-by:
Dave Marchevsky <davemarchevsky@fb.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20210416204704.2816874-4-davemarchevsky@fb.com
-
Dave Marchevsky authored
Add a bpf_iter test which feeds bpf_get_task_stack's return value into seq_write after confirming it's positive. No attempt to bound the value from above is made. Load will fail if verifier does not refine retval range based on buf sz input to bpf_get_task_stack. Signed-off-by:
-
Dave Marchevsky authored
Verifier can constrain the min/max bounds of bpf_get_task_stack's return value more tightly than the default tnum_unknown. Like bpf_get_stack, return value is num bytes written into a caller-supplied buf, or error, so do_refine_retval_range will work. Signed-off-by:
-
Yaqi Chen authored
>From commit c0bbbdc3 ("__netif_receive_skb_core: pass skb by reference"), the first argument passed into __netif_receive_skb_core has changed to reference of a skb pointer. This commit fixes by using bpf_probe_read_kernel. Signed-off-by:
Yaqi Chen <chendotjs@gmail.com> Signed-off-by:
-
- 19 Apr, 2021 7 commits
-
-
Alexei Starovoitov authored
Florent Revest says: ==================== We have a usecase where we want to audit symbol names (if available) in callback registration hooks. (ex: fentry/nf_register_net_hook) A few months back, I proposed a bpf_kallsyms_lookup series but it was decided in the reviews that a more generic helper, bpf_snprintf, would be more useful. This series implements the helper according to the feedback received in https://lore.kernel.org/bpf/20201126165748.1748417-1-revest@google.com/T/#u - A new arg type guarantees the NULL-termination of string arguments and lets us pass format strings in only one arg - A new helper is implemented using that guarantee. Because the format string is known at verification time, the format string validation is done by the verifier - To implement a series of tests for bpf_snprintf, the logic for marshalling variadic args in a fixed-size array is reworked as per: https://lore.kernel.org/bpf/20210310015455.1095207-1-revest@chromium.org/T/#u --- Changes in v5: - Fixed the bpf_printf_buf_used counter logic in try_get_fmt_tmp_buf - Added a couple of extra incorrect specifiers tests - Call test_snprintf_single__destroy unconditionally - Fixed a C++-style comment --- Changes in v4: - Moved bpf_snprintf, bpf_printf_prepare and bpf_printf_cleanup to kernel/bpf/helpers.c so that they get built without CONFIG_BPF_EVENTS - Added negative test cases (various invalid format strings) - Renamed put_fmt_tmp_buf() as bpf_printf_cleanup() - Fixed a mistake that caused temporary buffers to be unconditionally freed in bpf_printf_prepare - Fixed a mistake that caused missing 0 character to be ignored - Fixed a warning about integer to pointer conversion - Misc cleanups --- Changes in v3: - Simplified temporary buffer acquisition with try_get_fmt_tmp_buf() - Made zero-termination check more consistent - Allowed NULL output_buffer - Simplified the BPF_CAST_FMT_ARG macro - Three new test cases: number padding, simple string with no arg and string length extraction only with a NULL output buffer - Clarified helper's description for edge cases (eg: str_size == 0) - Lots of cosmetic changes --- Changes in v2: - Extracted the format validation/argument sanitization in a generic way for all printf-like helpers. - bpf_snprintf's str_size can now be 0 - bpf_snprintf is now exposed to all BPF program types - We now preempt_disable when using a per-cpu temporary buffer - Addressed a few cosmetic changes ==================== Acked-by:
-
Florent Revest authored
The "positive" part tests all format specifiers when things go well. The "negative" part makes sure that incorrect format strings fail at load time. Signed-off-by:
-
Florent Revest authored
Similarly to BPF_SEQ_PRINTF, this macro turns variadic arguments into an array of u64, making it more natural to call the bpf_snprintf helper. Signed-off-by:
-
Florent Revest authored
When initializing the __param array with a one liner, if all args are const, the initial array value will be placed in the rodata section but because libbpf does not support relocation in the rodata section, any pointer in this array will stay NULL. Fixes: c09add2f ("tools/libbpf: Add bpf_iter support") Signed-off-by:
-
Florent Revest authored
The implementation takes inspiration from the existing bpf_trace_printk helper but there are a few differences: To allow for a large number of format-specifiers, parameters are provided in an array, like in bpf_seq_printf. Because the output string takes two arguments and the array of parameters also takes two arguments, the format string needs to fit in one argument. Thankfully, ARG_PTR_TO_CONST_STR is guaranteed to point to a zero-terminated read-only map so we don't need a format string length arg. Because the format-string is known at verification time, we also do a first pass of format string validation in the verifier logic. This makes debugging easier. Signed-off-by:
-
Florent Revest authored
This type provides the guarantee that an argument is going to be a const pointer to somewhere in a read-only map value. It also checks that this pointer is followed by a zero character before the end of the map value. Signed-off-by:
-
Florent Revest authored
Two helpers (trace_printk and seq_printf) have very similar implementations of format string parsing and a third one is coming (snprintf). To avoid code duplication and make the code easier to maintain, this moves the operations associated with format string parsing (validation and argument sanitization) into one generic function. The implementation of the two existing helpers already drifted quite a bit so unifying them entailed a lot of changes: - bpf_trace_printk always expected fmt[fmt_size] to be the terminating NULL character, this is no longer true, the first 0 is terminating. - bpf_trace_printk now supports %% (which produces the percentage char). - bpf_trace_printk now skips width formating fields. - bpf_trace_printk now supports the X modifier (capital hexadecimal). - bpf_trace_printk now supports %pK, %px, %pB, %pi4, %pI4, %pi6 and %pI6 - argument casting on 32 bit has been simplified into one macro and using an enum instead of obscure int increments. - bpf_seq_printf now uses bpf_trace_copy_string instead of strncpy_from_kernel_nofault and handles the %pks %pus specifiers. - bpf_seq_printf now prints longs correctly on 32 bit architectures. - both were changed to use a global per-cpu tmp buffer instead of one stack buffer for trace_printk and 6 small buffers for seq_printf. - to avoid per-cpu buffer usage conflict, these helpers disable preemption while the per-cpu buffer is in use. - both helpers now support the %ps and %pS specifiers to print symbols. The implementation is also moved from bpf_trace.c to helpers.c because the upcoming bpf_snprintf helper will be made available to all BPF programs and will need it. Signed-off-by:
-
- 15 Apr, 2021 6 commits
-
-
Alexei Starovoitov authored
Yonghong Song says: ==================== To build kernel with clang, people typically use make -j60 LLVM=1 LLVM_IAS=1 LLVM_IAS=1 is not required for non-LTO build but is required for LTO build. In my environment, I am always having LLVM_IAS=1 regardless of whether LTO is enabled or not. After kernel is build with clang, the following command can be used to build selftests with clang: make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 I am using latest bpf-next kernel code base and latest clang built from source from https://github.com/llvm/llvm-project.git Using earlier version of llvm may have compilation errors, see tools/testing/selftests/bpf due to continuous development in llvm bpf features and selftests to use these features. To run bpf selftest properly, you need have certain necessary kernel configs like at: bpf-next:tools/testing/selftests/bpf/config (not that this is not a complete .config file and some other configs might still be needed.) Currently, using the above command, some compilations still use gcc and there are also compilation errors and warnings. This patch set intends to fix these issues. Patch #1 and #2 fixed the issue so clang/clang++ is used instead of gcc/g++. Patch #3 fixed a compilation failure. Patch #4 and #5 fixed various compiler warnings. Changelog: v2 -> v3: . more test environment description in cover letter. (Sedat) . use a different fix, but similar to other use in selftests/bpf Makefile, to exclude header files from CXX compilation command line. (Andrii) . fix codes instead of adding -Wno-format-security. (Andrii) v1 -> v2: . add -Wno-unused-command-line-argument and -Wno-format-security for clang only as (1). gcc does not exhibit those warnings, and (2). -Wno-unused-command-line-argument is only supported by clang. (Sedat) ==================== Signed-off-by:
-
Yonghong Song authored
With clang compiler: make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel # build selftests/bpf or bpftool make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 make -j60 -C tools/bpf/bpftool LLVM=1 LLVM_IAS=1 the following compilation warning showed up, net.c:160:37: warning: comparison of integers of different signs: '__u32' (aka 'unsigned int') and 'int' [-Wsign-compare] for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len); ^~~~~~~~~~~~~~~~~ .../tools/include/uapi/linux/netlink.h:99:24: note: expanded from macro 'NLMSG_OK' (nlh)->nlmsg_len <= (len)) ~~~~~~~~~~~~~~~~ ^ ~~~ In this particular case, "len" is defined as "int" and (nlh)->nlmsg_len is "unsigned int". The macro NLMSG_OK is defined as below in uapi/linux/netlink.h. #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ (nlh)->nlmsg_len <= (len)) The clang compiler complains the comparision "(nlh)->nlmsg_len <= (len))", but in bpftool/net.c, it is already ensured that "len > 0" must be true. So theoretically the compiler could deduce that comparison of "(nlh)->nlmsg_len" and "len" is okay, but this really depends on compiler internals. Let us add an explicit type conversion (from "int" to "unsigned int") for "len" in NLMSG_OK to silence this warning right now. Signed-off-by: -
Yonghong Song authored
With clang compiler: make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 Some linker flags are not used/effective for some binaries and we have warnings like: warning: -lelf: 'linker' input unused [-Wunused-command-line-argument] We also have warnings like: .../selftests/bpf/prog_tests/ns_current_pid_tgid.c:74:57: note: treat the string as an argument to avoid this if (CHECK(waitpid(cpid, &wstatus, 0) == -1, "waitpid", strerror(errno))) ^ "%s", .../selftests/bpf/test_progs.h:129:35: note: expanded from macro 'CHECK' _CHECK(condition, tag, duration, format) ^ .../selftests/bpf/test_progs.h:108:21: note: expanded from macro '_CHECK' fprintf(stdout, ##format); \ ^ The first warning can be silenced with clang option -Wno-unused-command-line-argument. For the second warning, source codes are modified as suggested by the compiler to silence the warning. Since gcc does not support the option -Wno-unused-command-line-argument and the warning only happens with clang compiler, the option -Wno-unused-command-line-argument is enabled only when clang compiler is used. Signed-off-by: -
Yonghong Song authored
With clang compiler: make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 the test_cpp build failed due to the failure: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated] clang-13: error: cannot specify -o when generating multiple output files test_cpp compilation flag looks like: clang++ -g -Og -rdynamic -Wall -I<...> ... \ -Dbpf_prog_load=bpf_prog_test_load -Dbpf_load_program=bpf_test_load_program \ test_cpp.cpp <...>/test_core_extern.skel.h <...>/libbpf.a <...>/test_stub.o \ -lcap -lelf -lz -lrt -lpthread -o <...>/test_cpp The clang++ compiler complains the header file in the command line and also failed the compilation due to this. Let us remove the header file from the command line which is not intended any way, and this fixed the compilation problem. Signed-off-by:
-
Yonghong Song authored
selftests/bpf/Makefile includes tools/scripts/Makefile.include. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed the case if CC/AR/LD/CXX/STRIP is allowed to be overridden, it will be written to clang/llvm-ar/..., instead of gcc binaries. The definition of CC_NO_CLANG is also relocated to the place after the above CC is defined. Signed-off-by:
-
Yonghong Song authored
selftests/bpf/Makefile includes lib.mk. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed lib.mk issue which sets CC to gcc in all cases. Signed-off-by:
-
