- 18 Jul, 2020 14 commits
-
-
Jakub Sitnicki authored
Exercise verifier access checks for bpf_sk_lookup context fields. Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200717103536.397595-15-jakub@cloudflare.com
-
Jakub Sitnicki authored
Make bpftool show human-friendly identifiers for newly introduced program and attach type, BPF_PROG_TYPE_SK_LOOKUP and BPF_SK_LOOKUP, respectively. Also, add the new prog type bash-completion, man page and help message. Signed-off-by:
-
Jakub Sitnicki authored
Make libbpf aware of the newly added program type, and assign it a section name. Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200717103536.397595-13-jakub@cloudflare.com
-
Jakub Sitnicki authored
Newly added program, context type and helper is used by tests in a subsequent patch. Synchronize the header file. Signed-off-by:
-
Jakub Sitnicki authored
Same as for udp4, let BPF program override the socket lookup result, by selecting a receiving socket of its choice or failing the lookup, if no connected UDP socket matched packet 4-tuple. Suggested-by:
Marek Majkowski <marek@cloudflare.com> Signed-off-by:
-
Jakub Sitnicki authored
Prepare for calling into reuseport from __udp6_lib_lookup as well. Signed-off-by:
-
Jakub Sitnicki authored
Following INET/TCP socket lookup changes, modify UDP socket lookup to let BPF program select a receiving socket before searching for a socket by destination address and port as usual. Lookup of connected sockets that match packet 4-tuple is unaffected by this change. BPF program runs, and potentially overrides the lookup result, only if a 4-tuple match was not found. Suggested-by:
-
Jakub Sitnicki authored
Prepare for calling into reuseport from __udp4_lib_lookup as well. Signed-off-by:
-
Jakub Sitnicki authored
Following ipv4 stack changes, run a BPF program attached to netns before looking up a listening socket. Program can return a listening socket to use as result of socket lookup, fail the lookup, or take no action. Suggested-by:
-
Jakub Sitnicki authored
Prepare for calling into reuseport from inet6_lookup_listener as well. Signed-off-by:
-
Jakub Sitnicki authored
Run a BPF program before looking up a listening socket on the receive path. Program selects a listening socket to yield as result of socket lookup by calling bpf_sk_assign() helper and returning SK_PASS code. Program can revert its decision by assigning a NULL socket with bpf_sk_assign(). Alternatively, BPF program can also fail the lookup by returning with SK_DROP, or let the lookup continue as usual with SK_PASS on return, when no socket has been selected with bpf_sk_assign(). This lets the user match packets with listening sockets freely at the last possible point on the receive path, where we know that packets are destined for local delivery after undergoing policing, filtering, and routing. With BPF code selecting the socket, directing packets destined to an IP range or to a port range to a single socket becomes possible. In case multiple programs are attached, they are run in series in the order in which they were attached. The end result is determined from return codes of all the programs according to following rules: 1. If any program returned SK_PASS and selected a valid socket, the socket is used as result of socket lookup. 2. If more than one program returned SK_PASS and selected a socket, last selection takes effect. 3. If any program returned SK_DROP, and no program returned SK_PASS and selected a socket, socket lookup fails with -ECONNREFUSED. 4. If all programs returned SK_PASS and none of them selected a socket, socket lookup continues to htable-based lookup. Suggested-by: -
Jakub Sitnicki authored
Prepare for calling into reuseport from __inet_lookup_listener as well. Signed-off-by:
-
Jakub Sitnicki authored
Add a new program type BPF_PROG_TYPE_SK_LOOKUP with a dedicated attach type BPF_SK_LOOKUP. The new program kind is to be invoked by the transport layer when looking up a listening socket for a new connection request for connection oriented protocols, or when looking up an unconnected socket for a packet for connection-less protocols. When called, SK_LOOKUP BPF program can select a socket that will receive the packet. This serves as a mechanism to overcome the limits of what bind() API allows to express. Two use-cases driving this work are: (1) steer packets destined to an IP range, on fixed port to a socket 192.0.2.0/24, port 80 -> NGINX socket (2) steer packets destined to an IP address, on any port to a socket 198.51.100.1, any port -> L7 proxy socket In its run-time context program receives information about the packet that triggered the socket lookup. Namely IP version, L4 protocol identifier, and address 4-tuple. Context can be further extended to include ingress interface identifier. To select a socket BPF program fetches it from a map holding socket references, like SOCKMAP or SOCKHASH, and calls bpf_sk_assign(ctx, sk, ...) helper to record the selection. Transport layer then uses the selected socket as a result of socket lookup. In its basic form, SK_LOOKUP acts as a filter and hence must return either SK_PASS or SK_DROP. If the program returns with SK_PASS, transport should look for a socket to receive the packet, or use the one selected by the program if available, while SK_DROP informs the transport layer that the lookup should fail. This patch only enables the user to attach an SK_LOOKUP program to a network namespace. Subsequent patches hook it up to run on local delivery path in ipv4 and ipv6 stacks. Suggested-by: -
Jakub Sitnicki authored
Extend the BPF netns link callbacks to rebuild (grow/shrink) or update the prog_array at given position when link gets attached/updated/released. This let's us lift the limit of having just one link attached for the new attach type introduced by subsequent patch. No functional changes intended. Signed-off-by:
-
- 16 Jul, 2020 26 commits
-
-
Randy Dunlap authored
Drop doubled words "will" and "attach". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/6b9f71ae-4f8e-0259-2c5d-187ddaefe6eb@infradead.org
-
Stanislav Fomichev authored
Andrii reported that sockopt_inherit occasionally hangs up on 5.5 kernel [0]. This can happen if server_thread runs faster than the main thread. In that case, pthread_cond_wait will wait forever because pthread_cond_signal was executed before the main thread was blocking. Let's move pthread_mutex_lock up a bit to make sure server_thread runs strictly after the main thread goes to sleep. (Not sure why this is 5.5 specific, maybe scheduling is less deterministic? But I was able to confirm that it does indeed happen in a VM.) [0] https://lore.kernel.org/bpf/CAEf4BzY0-bVNHmCkMFPgObs=isUAyg-dFzGDY7QWYkmm7rmTSg@mail.gmail.com/Reported-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
-
Seth Forshee authored
This reverts commit 3203c901 ("test_bpf: flag tests that cannot be jited on s390"). The s390 bpf JIT previously had a restriction on the maximum program size, which required some tests in test_bpf to be flagged as expected failures. The program size limitation has been removed, and the tests now pass, so these tests should no longer be flagged. Fixes: d1242b10 ("s390/bpf: Remove JITed image size limitations") Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/bpf/20200716143931.330122-1-seth.forshee@canonical.com
-
Lorenzo Bianconi authored
Similar to what have been done for DEVMAP, introduce tests to verify ability to add a XDP program to an entry in a CPUMAP. Verify CPUMAP programs can not be attached to devices as a normal XDP program, and only programs with BPF_XDP_CPUMAP attach type can be loaded in a CPUMAP. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Extend xdp_redirect_cpu_{usr,kern}.c adding the possibility to load a XDP program on cpumap entries. The following options have been added: - mprog-name: cpumap entry program name - mprog-filename: cpumap entry program filename - redirect-device: output interface if the cpumap program performs a XDP_REDIRECT to an egress interface - redirect-map: bpf map used to perform XDP_REDIRECT to an egress interface - mprog-disable: disable loading XDP program on cpumap entries Add xdp_pass, xdp_drop, xdp_redirect stats accounting Co-developed-by:Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Lorenzo Bianconi authored
As for DEVMAP, support SEC("xdp_cpumap/") as a short cut for loading the program with type BPF_PROG_TYPE_XDP and expected attach type BPF_XDP_CPUMAP. Signed-off-by: -
Lorenzo Bianconi authored
Introduce XDP_REDIRECT support for eBPF programs attached to cpumap entries. This patch has been tested on Marvell ESPRESSObin using a modified version of xdp_redirect_cpu sample in order to attach a XDP program to CPUMAP entries to perform a redirect on the mvneta interface. In particular the following scenario has been tested: rq (cpu0) --> mvneta - XDP_REDIRECT (cpu0) --> CPUMAP - XDP_REDIRECT (cpu1) --> mvneta $./xdp_redirect_cpu -p xdp_cpu_map0 -d eth0 -c 1 -e xdp_redirect \ -f xdp_redirect_kern.o -m tx_port -r eth0 tx: 285.2 Kpps rx: 285.2 Kpps Attaching a simple XDP program on eth0 to perform XDP_TX gives comparable results: tx: 288.4 Kpps rx: 288.4 Kpps Co-developed-by:
-
Lorenzo Bianconi authored
Introduce the capability to attach an eBPF program to cpumap entries. The idea behind this feature is to add the possibility to define on which CPU run the eBPF program if the underlying hw does not support RSS. Current supported verdicts are XDP_DROP and XDP_PASS. This patch has been tested on Marvell ESPRESSObin using xdp_redirect_cpu sample available in the kernel tree to identify possible performance regressions. Results show there are no observable differences in packet-per-second: $./xdp_redirect_cpu --progname xdp_cpu_map0 --dev eth0 --cpu 1 rx: 354.8 Kpps rx: 356.0 Kpps rx: 356.8 Kpps rx: 356.3 Kpps rx: 356.6 Kpps rx: 356.6 Kpps rx: 356.7 Kpps rx: 355.8 Kpps rx: 356.8 Kpps rx: 356.8 Kpps Co-developed-by:
-
Lorenzo Bianconi authored
As it has been already done for devmap, introduce 'struct bpf_cpumap_val' to formalize the expected values that can be passed in for a CPUMAP. Update cpumap code to use the struct. Signed-off-by:
-
Lorenzo Bianconi authored
Do not update xdp_redirect_cpu maps running while option loop but defer it after all available options have been parsed. This is a preliminary patch to pass the program name we want to attach to the map entries as a user option Signed-off-by:
-
David Ahern authored
Move the guts of xdp_convert_buff_to_frame to a new helper, xdp_update_frame_from_buff so it can be reused removing code duplication Suggested-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Jesper Dangaard Brouer authored
Commit 77361825 ("bpf: cpumap use ptr_ring_consume_batched") changed away from using single frame ptr_ring dequeue (__ptr_ring_consume) to consume a batched, but it uses a locked version, which as the comment explain isn't needed. Change to use the non-locked version __ptr_ring_consume_batched. Fixes: 77361825 ("bpf: cpumap use ptr_ring_consume_batched") Signed-off-by:
-
Randy Dunlap authored
Drop the doubled word "by" in a comment. Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Randy Dunlap authored
Drop doubled words in several comments. Signed-off-by:
-
Randy Dunlap authored
Drop doubled word "the" in a comment. Signed-off-by:
-
Randy Dunlap authored
Drop doubled word "to" in a comment. Signed-off-by:
-
Randy Dunlap authored
Drop doubled words "or" and "the" in several comments. Signed-off-by:
-
Randy Dunlap authored
Drop doubled word "not" in a comment. Signed-off-by:
-
Randy Dunlap authored
Drop doubled words in two comments. Fix a spello/typo. Signed-off-by:
-
Randy Dunlap authored
Drop doubled words in several comments. Signed-off-by:
-
Randy Dunlap authored
Drop doubled word "the" in two comments. Signed-off-by:
-
Kieran Bingham authored
The word 'descriptor' is misspelled throughout the tree. Fix it up accordingly: decriptor -> descriptor Signed-off-by:Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Offload tc police action This patch set adds support for tc police action in mlxsw. Patches #1-#2 add defines for policer bandwidth limits and resource identifiers (e.g., maximum number of policers). Patch #3 adds a common policer core in mlxsw. Currently it is only used by the policy engine, but future patch sets will use it for trap policers and storm control policers. The common core allows us to share common logic between all policer types and abstract certain details from the various users in mlxsw. Patch #4 exposes the maximum number of supported policers and their current usage to user space via devlink-resource. This provides better visibility and also used for selftests purposes. Patches #5-#7 gradually add support for tc police action in the policy engine by calling into previously mentioned policer core. Patch #8 adds a generic selftest for tc-police that can be used with veth pairs or physical loopbacks. Patches #9-#11 add mlxsw-specific selftests. ==================== Signed-off-by: -
Ido Schimmel authored
Test that policers shared by different tc filters are correctly reference counted by observing policers' occupancy via devlink-resource. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Query the maximum number of supported policers using devlink-resource and test that this number can be reached by configuring tc filters with police action. Test that an error is returned in case the maximum number is exceeded. Signed-off-by:
-
Ido Schimmel authored
Test that upper and lower limits on rate and burst size imposed by the device are rejected by the kernel. Signed-off-by:
-
