- 27 Jul, 2020 1 commit
-
-
Quentin Monnet authored
For probing program and map types, bpftool loops on type values and uses the relevant type name in prog_type_name[] or map_type_name[]. To ensure the name exists, we exit from the loop if we go over the size of the array. However, this is not enough in the case where the arrays have "holes" in them, program or map types for which they have no name, but not at the end of the list. This is currently the case for BPF_PROG_TYPE_LSM, not known to bpftool and which name is a null string. When probing for features, bpftool attempts to strlen() that name and segfaults. Let's fix it by skipping probes for "unknown" program and map types, with an informational message giving the numeral value in that case. Fixes: 93a3545d ("tools/bpftool: Add name mappings for SK_LOOKUP prog and attach type") Reported-by:
Paul Chaignon <paul@cilium.io> Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200724090618.16378-2-quentin@isovalent.com
-
- 26 Jul, 2020 39 commits
-
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== Following cgroup and netns examples, implement bpf_link support for XDP. The semantics is described in patch #2. Program and link attachments are mutually exclusive, in the sense that neither link can replace attached program nor program can replace attached link. Link can't replace attached link as well, as is the case for any other bpf_link implementation. Patch #1 refactors existing BPF program-based attachment API and centralizes high-level query/attach decisions in generic kernel code, while drivers are kept simple and are instructed with low-level decisions about attaching and detaching specific bpf_prog. This also makes QUERY command unnecessary, and patch #8 removes support for it from all kernel drivers. If that's a bad idea, we can drop that patch altogether. With refactoring in patch #1, adding bpf_xdp_link is completely transparent to drivers, they are still functioning at the level of "effective" bpf_prog, that should be called in XDP data path. Corresponding libbpf support for BPF XDP link is added in patch #5. v3->v4: - fix a compilation warning in one of drivers (Jakub); v2->v3: - fix build when CONFIG_BPF_SYSCALL=n (kernel test robot); v1->v2: - fix prog refcounting bug (David); - split dev_change_xdp_fd() changes into 2 patches (David); - add extack messages to all user-induced errors (David). ==================== Signed-off-by:Alexei Starovoitov <ast@kernel.org>
-
Andrii Nakryiko authored
Now that BPF program/link management is centralized in generic net_device code, kernel code never queries program id from drivers, so XDP_QUERY_PROG/XDP_QUERY_PROG_HW commands are unnecessary. This patch removes all the implementations of those commands in kernel, along the xdp_attachment_query(). This patch was compile-tested on allyesconfig. Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
Andrii Nakryiko authored
Add selftest validating all the attachment logic around BPF XDP link. Test also link updates and get_obj_info() APIs. Signed-off-by:
-
Andrii Nakryiko authored
Sync UAPI header and add support for using bpf_link-based XDP attachment. Make xdp/ prog type set expected attach type. Kernel didn't enforce attach_type for XDP programs before, so there is no backwards compatiblity issues there. Also fix section_names selftest to recognize that xdp prog types now have expected attach type. Signed-off-by:
-
Andrii Nakryiko authored
Implement XDP link-specific show_fdinfo and link_info to emit ifindex. Signed-off-by:
-
Andrii Nakryiko authored
Add support for LINK_UPDATE command for BPF XDP link to enable reliable replacement of underlying BPF program. Signed-off-by:
-
Andrii Nakryiko authored
Add bpf_link-based API (bpf_xdp_link) to attach BPF XDP program through BPF_LINK_CREATE command. bpf_xdp_link is mutually exclusive with direct BPF program attachment, previous BPF program should be detached prior to attempting to create a new bpf_xdp_link attachment (for a given XDP mode). Once BPF link is attached, it can't be replaced by other BPF program attachment or link attachment. It will be detached only when the last BPF link FD is closed. bpf_xdp_link will be auto-detached when net_device is shutdown, similarly to how other BPF links behave (cgroup, flow_dissector). At that point bpf_link will become defunct, but won't be destroyed until last FD is closed. Signed-off-by:
-
Andrii Nakryiko authored
Further refactor XDP attachment code. dev_change_xdp_fd() is split into two parts: getting bpf_progs from FDs and attachment logic, working with bpf_progs. This makes attachment logic a bit more straightforward and prepares code for bpf_xdp_link inclusion, which will share the common logic. Signed-off-by:
-
Andrii Nakryiko authored
Instead of delegating to drivers, maintain information about which BPF programs are attached in which XDP modes (generic/skb, driver, or hardware) locally in net_device. This effectively obsoletes XDP_QUERY_PROG command. Such re-organization simplifies existing code already. But it also allows to further add bpf_link-based XDP attachments without drivers having to know about any of this at all, which seems like a good setup. XDP_SETUP_PROG/XDP_SETUP_PROG_HW are just low-level commands to driver to install/uninstall active BPF program. All the higher-level concerns about prog/link interaction will be contained within generic driver-agnostic logic. All the XDP_QUERY_PROG calls to driver in dev_xdp_uninstall() were removed. It's not clear for me why dev_xdp_uninstall() were passing previous prog_flags when resetting installed programs. That seems unnecessary, plus most drivers don't populate prog_flags anyways. Having XDP_SETUP_PROG vs XDP_SETUP_PROG_HW should be enough of an indicator of what is required of driver to correctly reset active BPF program. dev_xdp_uninstall() is also generalized as an iteration over all three supported mode. Signed-off-by:
-
Andrii Nakryiko authored
Similarly to bpf_prog, make bpf_link and related generic API available unconditionally to make it easier to have bpf_link support in various parts of the kernel. Stub out init/prime/settle/cleanup and inc/put APIs. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Song Liu authored
Architectures like s390, powerpc, arm64, riscv have speical definition of bpf_user_pt_regs_t. So we need to cast the pointer before passing it to bpf_get_stack(). This is similar to bpf_get_stack_tp(). Fixes: 03d42fd2d83f ("bpf: Separate bpf_get_[stack|stackid] for perf events BPF") Reported-by:Song Liu <songliubraving@fb.com> Signed-off-by:
-
YiFei Zhu authored
local_storage.o has its compile guard as CONFIG_BPF_SYSCALL, which does not imply that CONFIG_CGROUP is on. Including cgroup-internal.h when CONFIG_CGROUP is off cause a compilation failure. Fixes: f67cfc233706 ("bpf: Make cgroup storages shared between programs on the same cgroup") Reported-by:YiFei Zhu <zhuyifei@google.com> Signed-off-by:
-
Alexei Starovoitov authored
YiFei Zhu says: ==================== To access the storage in a CGROUP_STORAGE map, one uses bpf_get_local_storage helper, which is extremely fast due to its use of per-CPU variables. However, its whole code is built on the assumption that one map can only be used by one program at any time, and this prohibits any sharing of data between multiple programs using these maps, eliminating a lot of use cases, such as some per-cgroup configuration storage, written to by a setsockopt program and read by a cg_sock_addr program. Why not use other map types? The great part of CGROUP_STORAGE map is that it is isolated by different cgroups its attached to. When one program uses bpf_get_local_storage, even on the same map, it gets different storages if it were run as a result of attaching to different cgroups. The kernel manages the storages, simplifying BPF program or userspace. In theory, one could probably use other maps like array or hash to do the same thing, but it would be a major overhead / complexity. Userspace needs to know when a cgroup is being freed in order to free up a space in the replacement map. This patch set introduces a significant change to the semantics of CGROUP_STORAGE map type. Instead of each storage being tied to one single attachment, it is shared across different attachments to the same cgroup, and persists until either the map or the cgroup attached to is being freed. User may use u64 as the key to the map, and the result would be that the attach type become ignored during key comparison, and programs of different attach types will share the same storage if the cgroups they are attached to are the same. How could this break existing users? * Users that uses detach & reattach / program replacement as a shortcut to zeroing the storage. Since we need sharing between programs, we cannot zero the storage. Users that expect this behavior should either attach a program with a new map, or explicitly zero the map with a syscall. This case is dependent on undocumented implementation details, so the impact should be very minimal. Patch 1 introduces a test on the old expected behavior of the map type. Patch 2 introduces a test showing how two programs cannot share one such map. Patch 3 implements the change of semantics to the map. Patch 4 amends the new test such that it yields the behavior we expect from the change. Patch 5 documents the map type. Changes since RFC: * Clarify commit message in patch 3 such that it says the lifetime of the storage is ended at the freeing of the cgroup_bpf, rather than the cgroup itself. * Restored an -ENOMEM check in __cgroup_bpf_attach. * Update selftests for recent change in network_helpers API. Changes since v1: * s/CHECK_FAIL/CHECK/ * s/bpf_prog_attach/bpf_program__attach_cgroup/ * Moved test__start_subtest to test_cg_storage_multi. * Removed some redundant CHECK_FAIL where they are already CHECK-ed. Changes since v2: * Lock cgroup_mutex during map_free. * Publish new storages only if attach is successful, by tracking exactly which storages are reused in an array of bools. * Mention bpftool map dump showing a value of zero for attach_type in patch 3 commit message. Changes since v3: * Use a much simpler lookup and allocate-if-not-exist from the fact that cgroup_mutex is locked during attach. * Removed an unnecessary spinlock hold. Changes since v4: * Changed semantics so that if the key type is struct bpf_cgroup_storage_key the map retains isolation between different attach types. Sharing between different attach types only occur when key type is u64. * Adapted tests and docs for the above change. Changes since v5: * Removed redundant NULL check before bpf_link__destroy. * Free BPF object explicitly, after asserting that object failed to load, in the event that the object did not fail to load. * Rename variable in bpf_cgroup_storage_key_cmp for clarity. * Added a lot of information to Documentation, more or less copied from what Martin KaFai Lau wrote. ==================== Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
-
YiFei Zhu authored
The machanics and usage are not very straightforward. Given the changes it's better to document how it works and how to use it, rather than having to rely on the examples and implementation to infer what is going on. Signed-off-by:
-
YiFei Zhu authored
This mirrors the original egress-only test. The cgroup_storage is now extended to have two packet counters, one for egress and one for ingress. We also extend to have two egress programs to test that egress will always share with other egress origrams in the same cgroup. The behavior of the counters are exactly the same as the original egress-only test. The test is split into two, one "isolated" test that when the key type is struct bpf_cgroup_storage_key, which contains the attach type, programs of different attach types will see different storages. The other, "shared" test that when the key type is u64, programs of different attach types will see the same storage if they are attached to the same cgroup. Signed-off-by:
-
Alexei Starovoitov authored
Song Liu says: ==================== Calling get_perf_callchain() on perf_events from PEBS entries may cause unwinder errors. To fix this issue, perf subsystem fetches callchain early, and marks perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY. Similar issue exists when BPF program calls get_perf_callchain() via helper functions. For more information about this issue, please refer to discussions in [1]. This set fixes this issue with helper proto bpf_get_stackid_pe and bpf_get_stack_pe. [1] https://lore.kernel.org/lkml/ED7B9430-6489-4260-B3C5-9CFA2E3AA87A@fb.com/ Changes v4 => v5: 1. Return -EPROTO instead of -EINVAL on PERF_EVENT_IOC_SET_BPF errors. (Alexei) 2. Let libbpf print a hint message when PERF_EVENT_IOC_SET_BPF returns -EPROTO. (Alexei) Changes v3 => v4: 1. Fix error check logic in bpf_get_stackid_pe and bpf_get_stack_pe. (Alexei) 2. Do not allow attaching BPF programs with bpf_get_stack|stackid to perf_event with precise_ip > 0, but not proper callchain. (Alexei) 3. Add selftest get_stackid_cannot_attach. Changes v2 => v3: 1. Fix handling of stackmap skip field. (Andrii) 2. Simplify the code in a few places. (Andrii) Changes v1 => v2: 1. Simplify the design and avoid introducing new helper function. (Andrii) ==================== Signed-off-by:
-
YiFei Zhu authored
This change comes in several parts: One, the restriction that the CGROUP_STORAGE map can only be used by one program is removed. This results in the removal of the field 'aux' in struct bpf_cgroup_storage_map, and removal of relevant code associated with the field, and removal of now-noop functions bpf_free_cgroup_storage and bpf_cgroup_storage_release. Second, we permit a key of type u64 as the key to the map. Providing such a key type indicates that the map should ignore attach type when comparing map keys. However, for simplicity newly linked storage will still have the attach type at link time in its key struct. cgroup_storage_check_btf is adapted to accept u64 as the type of the key. Third, because the storages are now shared, the storages cannot be unconditionally freed on program detach. There could be two ways to solve this issue: * A. Reference count the usage of the storages, and free when the last program is detached. * B. Free only when the storage is impossible to be referred to again, i.e. when either the cgroup_bpf it is attached to, or the map itself, is freed. Option A has the side effect that, when the user detach and reattach a program, whether the program gets a fresh storage depends on whether there is another program attached using that storage. This could trigger races if the user is multi-threaded, and since nondeterminism in data races is evil, go with option B. The both the map and the cgroup_bpf now tracks their associated storages, and the storage unlink and free are removed from cgroup_bpf_detach and added to cgroup_bpf_release and cgroup_storage_map_free. The latter also new holds the cgroup_mutex to prevent any races with the former. Fourth, on attach, we reuse the old storage if the key already exists in the map, via cgroup_storage_lookup. If the storage does not exist yet, we create a new one, and publish it at the last step in the attach process. This does not create a race condition because for the whole attach the cgroup_mutex is held. We keep track of an array of new storages that was allocated and if the process fails only the new storages would get freed. Signed-off-by: -
Song Liu authored
This test confirms that BPF program that calls bpf_get_stackid() cannot attach to perf_event with precise_ip > 0 but not PERF_SAMPLE_CALLCHAIN; and cannot attach if the perf_event has exclude_callchain_kernel. Signed-off-by:
-
YiFei Zhu authored
The current assumption is that the lifetime of a cgroup storage is tied to the program's attachment. The storage is created in cgroup_bpf_attach, and released upon cgroup_bpf_detach and cgroup_bpf_release. Because the current semantics is that each attachment gets a completely independent cgroup storage, and you can have multiple programs attached to the same (cgroup, attach type) pair, the key of the CGROUP_STORAGE map, looking up the map with this pair could yield multiple storages, and that is not permitted. Therefore, the kernel verifier checks that two programs cannot share the same CGROUP_STORAGE map, even if they have different expected attach types, considering that the actual attach type does not always have to be equal to the expected attach type. The test creates a CGROUP_STORAGE map and make it shared across two different programs, one cgroup_skb/egress and one /ingress. It asserts that the two programs cannot be both loaded, due to verifier failure from the above reason. Signed-off-by:
-
Song Liu authored
This tests new helper function bpf_get_stackid_pe and bpf_get_stack_pe. These two helpers have different implementation for perf_event with PEB entries. Signed-off-by:
-
YiFei Zhu authored
This test creates a parent cgroup, and a child of that cgroup. It attaches a cgroup_skb/egress program that simply counts packets, to a global variable (ARRAY map), and to a CGROUP_STORAGE map. The program is first attached to the parent cgroup only, then to parent and child. The test cases sends a message within the child cgroup, and because the program is inherited across parent / child cgroups, it will trigger the egress program for both the parent and child, if they exist. The program, when looking up a CGROUP_STORAGE map, uses the cgroup and attach type of the attachment parameters; therefore, both attaches uses different cgroup storages. We assert that all packet counts returns what we expects. Signed-off-by:
-
Song Liu authored
The kernel prevents potential unwinder warnings and crashes by blocking BPF program with bpf_get_[stack|stackid] on perf_event without PERF_SAMPLE_CALLCHAIN, or with exclude_callchain_[kernel|user]. Print a hint message in libbpf to help the user debug such issues. Signed-off-by:
-
Alexei Starovoitov authored
Yonghong Song says: ==================== Bpf iterator has been implemented for task, task_file, bpf_map, ipv6_route, netlink, tcp and udp so far. For map elements, there are two ways to traverse all elements from user space: 1. using BPF_MAP_GET_NEXT_KEY bpf subcommand to get elements one by one. 2. using BPF_MAP_LOOKUP_BATCH bpf subcommand to get a batch of elements. Both these approaches need to copy data from kernel to user space in order to do inspection. This patch implements bpf iterator for map elements. User can have a bpf program in kernel to run with each map element, do checking, filtering, aggregation, modifying values etc. without copying data to user space. Patch #1 and #2 are refactoring. Patch #3 implements readonly/readwrite buffer support in verifier. Patches #4 - #7 implements map element support for hash, percpu hash, lru hash lru percpu hash, array, percpu array and sock local storage maps. Patches #8 - #9 are libbpf and bpftool support. Patches #10 - #13 are selftests for implemented map element iterators. Changelogs: v3 -> v4: . fix a kasan failure triggered by a failed bpf_iter link_create, not just free_link but need cleanup_link. (Alexei) v2 -> v3: . rebase on top of latest bpf-next v1 -> v2: . support to modify map element values. (Alexei) . map key/values can be used with helper arguments for those arguments with ARG_PTR_TO_MEM or ARG_PTR_TO_INIT_MEM register type. (Alexei) . remove usused variable. (kernel test robot) ==================== Signed-off-by: -
Song Liu authored
bpf_get_[stack|stackid] on perf_events with precise_ip uses callchain attached to perf_sample_data. If this callchain is not presented, do not allow attaching BPF program that calls bpf_get_[stack|stackid] to this event. In the error case, -EPROTO is returned so that libbpf can identify this error and print proper hint message. Signed-off-by:
-
Yonghong Song authored
If the bpf program contains out of bound access w.r.t. a particular map key/value size, the verification will be still okay, e.g., it will be accepted by verifier. But it will be rejected during link_create time. A test is added here to ensure link_create failure did happen if out of bound access happened. $ ./test_progs -n 4 ... #4/23 rdonly-buf-out-of-bound:OK ... Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Song Liu authored
Calling get_perf_callchain() on perf_events from PEBS entries may cause unwinder errors. To fix this issue, the callchain is fetched early. Such perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY. Similarly, calling bpf_get_[stack|stackid] on perf_events from PEBS may also cause unwinder errors. To fix this, add separate version of these two helpers, bpf_get_[stack|stackid]_pe. These two hepers use callchain in bpf_perf_event_data_kern->data->callchain. Signed-off-by:
-
Yonghong Song authored
Added one test for bpf sk_storage_map_iterator. $ ./test_progs -n 4 ... #4/22 bpf_sk_storage_map:OK ... Signed-off-by:
-
Yonghong Song authored
Two subtests are added. $ ./test_progs -n 4 ... #4/20 bpf_array_map:OK #4/21 bpf_percpu_array_map:OK ... The bpf_array_map subtest also tested bpf program changing array element values and send key/value to user space through bpf_seq_write() interface. Signed-off-by:
-
Yonghong Song authored
Two subtests are added. $ ./test_progs -n 4 ... #4/18 bpf_hash_map:OK #4/19 bpf_percpu_hash_map:OK ... Signed-off-by:
-
Yonghong Song authored
The optional parameter "map MAP" can be added to "bpftool iter" command to create a bpf iterator for map elements. For example, bpftool iter pin ./prog.o /sys/fs/bpf/p1 map id 333 For map element bpf iterator "map MAP" parameter is required. Otherwise, bpf link creation will return an error. Quentin Monnet kindly provided bash-completion implementation for new "map MAP" option. Signed-off-by:
-
Yonghong Song authored
Add map_fd to bpf_iter_attach_opts and flags to bpf_link_create_opts. Later on, bpftool or selftest will be able to create a bpf map element iterator by passing map_fd to the kernel during link creation time. Signed-off-by:
-
Yonghong Song authored
The bpf iterator for bpf sock local storage map is implemented. User space interacts with sock local storage map with fd as a key and storage value. In kernel, passing fd to the bpf program does not really make sense. In this case, the sock itself is passed to bpf program. Signed-off-by:
-
Yonghong Song authored
The bpf iterators for array and percpu array are implemented. Similar to hash maps, for percpu array map, bpf program will receive values from all cpus. Signed-off-by:
-
Yonghong Song authored
The bpf iterators for hash, percpu hash, lru hash and lru percpu hash are implemented. During link time, bpf_iter_reg->check_target() will check map type and ensure the program access key/value region is within the map defined key/value size limit. For percpu hash and lru hash maps, the bpf program will receive values for all cpus. The map element bpf iterator infrastructure will prepare value properly before passing the value pointer to the bpf program. This patch set supports readonly map keys and read/write map values. It does not support deleting map elements, e.g., from hash tables. If there is a user case for this, the following mechanism can be used to support map deletion for hashtab, etc. - permit a new bpf program return value, e.g., 2, to let bpf iterator know the map element should be removed. - since bucket lock is taken, the map element will be queued. - once bucket lock is released after all elements under this bucket are traversed, all to-be-deleted map elements can be deleted. Signed-off-by: -
Alexei Starovoitov authored
It's mostly a copy paste of commit 6086d29d ("bpf: Add bpf_map iterator") that is use to implement bpf_seq_file opreations to traverse all bpf programs. v1->v2: Tweak to use build time btf_id Signed-off-by:
-
Yonghong Song authored
The bpf iterator for map elements are implemented. The bpf program will receive four parameters: bpf_iter_meta *meta: the meta data bpf_map *map: the bpf_map whose elements are traversed void *key: the key of one element void *value: the value of the same element Here, meta and map pointers are always valid, and key has register type PTR_TO_RDONLY_BUF_OR_NULL and value has register type PTR_TO_RDWR_BUF_OR_NULL. The kernel will track the access range of key and value during verification time. Later, these values will be compared against the values in the actual map to ensure all accesses are within range. A new field iter_seq_info is added to bpf_map_ops which is used to add map type specific information, i.e., seq_ops, init/fini seq_file func and seq_file private data size. Subsequent patches will have actual implementation for bpf_map_ops->iter_seq_info. In user space, BPF_ITER_LINK_MAP_FD needs to be specified in prog attr->link_create.flags, which indicates that attr->link_create.target_fd is a map_fd. The reason for such an explicit flag is for possible future cases where one bpf iterator may allow more than one possible customization, e.g., pid and cgroup id for task_file. Current kernel internal implementation only allows the target to register at most one required bpf_iter_link_info. To support the above case, optional bpf_iter_link_info's are needed, the target can be extended to register such link infos, and user provided link_info needs to match one of target supported ones. Signed-off-by:
-
Yonghong Song authored
Currently, the pos pointer in bpf iterator map/task/task_file seq_ops->start() is always incremented. This is incorrect. It should be increased only if *pos is 0 (for SEQ_START_TOKEN) since these start() function actually returns the first real object. If *pos is not 0, it merely found the object based on the state in seq->private, and not really advancing the *pos. This patch fixed this issue by only incrementing *pos if it is 0. Note that the old *pos calculation, although not correct, does not affect correctness of bpf_iter as bpf_iter seq_file->read() does not support llseek. This patch also renamed "mid" in bpf_map iterator seq_file private data to "map_id" for better clarity. Fixes: 6086d29d ("bpf: Add bpf_map iterator") Fixes: eaaacd23 ("bpf: Add task and task/file iterator targets") Signed-off-by:
-
Yonghong Song authored
Readonly and readwrite buffer register states are introduced. Totally four states, PTR_TO_RDONLY_BUF[_OR_NULL] and PTR_TO_RDWR_BUF[_OR_NULL] are supported. As suggested by their respective names, PTR_TO_RDONLY_BUF[_OR_NULL] are for readonly buffers and PTR_TO_RDWR_BUF[_OR_NULL] for read/write buffers. These new register states will be used by later bpf map element iterator. New register states share some similarity to PTR_TO_TP_BUFFER as it will calculate accessed buffer size during verification time. The accessed buffer size will be later compared to other metrics during later attach/link_create time. Similar to reg_state PTR_TO_BTF_ID_OR_NULL in bpf iterator programs, PTR_TO_RDONLY_BUF_OR_NULL or PTR_TO_RDWR_BUF_OR_NULL reg_types can be set at prog->aux->bpf_ctx_arg_aux, and bpf verifier will retrieve the values during btf_ctx_access(). Later bpf map element iterator implementation will show how such information will be assigned during target registeration time. The verifier is also enhanced such that PTR_TO_RDONLY_BUF can be passed to ARG_PTR_TO_MEM[_OR_NULL] helper argument, and PTR_TO_RDWR_BUF can be passed to ARG_PTR_TO_MEM[_OR_NULL] or ARG_PTR_TO_UNINIT_MEM. Signed-off-by:
-
Jakub Sitnicki authored
Cover the case when BPF socket lookup returns a socket that belongs to a reuseport group, and the reuseport group contains connected UDP sockets. Ensure that the presence of connected UDP sockets in reuseport group does not affect the socket lookup result. Socket selected by reuseport should always be used as result in such case. Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Link: https://lore.kernel.org/bpf/20200722161720.940831-3-jakub@cloudflare.com
-
