- 02 Feb, 2019 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Alexei Starovoitov says: ==================== pull-request: bpf-next 2019-02-01 The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) introduce bpf_spin_lock, from Alexei. 2) convert xdp samples to libbpf, from Maciej. 3) skip verifier tests for unsupported program/map types, from Stanislav. 4) powerpc64 JIT support for BTF line info, from Sandipan. 5) assorted fixed, from Valdis, Jesper, Jiong. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Alexei Starovoitov authored
Jiong Wang says: ==================== NFP JIT back-end is missing several ALU32 logic shifts support. Also, shifts with shift amount be zero are not handled properly. This set cleans up these issues. ==================== Signed-off-by:Alexei Starovoitov <ast@kernel.org>
-
Jiong Wang authored
The following ALU32 logic shift supports are missing: BPF_ALU | BPF_LSH | BPF_X BPF_ALU | BPF_RSH | BPF_X BPF_ALU | BPF_RSH | BPF_K For BPF_RSH | BPF_K, it could be implemented using NFP direct shift instruction. For the other BPF_X shifts, NFP indirect shifts sequences need to be used. Separate code-gen hook is assigned to each instruction to make the implementation clear. Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Jiong Wang <jiong.wang@netronome.com> Signed-off-by:
-
Jiong Wang authored
Shifts by zero do nothing, and should be treated as nops. Even though compiler is not supposed to generate such instructions and manual written assembly is unlikely to have them, but they are legal instructions and have defined behavior. This patch correct existing shifts code-gen to make sure they do nothing when shift amount is zero except when the instruction is ALU32 for which high bits need to be cleared. For shift amount bigger than type size, already, NFP JIT back-end errors out for immediate shift and only low 5 bits will be taken into account for indirect shift which is the same as x86. Reviewed-by:
-
- 01 Feb, 2019 36 commits
-
-
Stanislav Fomichev authored
'make clean' is supposed to remove generated files. Signed-off-by:
Stanislav Fomichev <sdf@google.com> Acked-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== devlink: add device (driver) information API fw_version field in ethtool -i does not suit modern needs with 31 characters being quite limiting on more complex systems. There is also no distinction between the running and flashed versions of the firmware. Since the driver information pertains to the entire device, rather than a particular netdev, it seems wise to move it do devlink, at the same time fixing the aforementioned issues. The new API allows exposing the device serial number and versions of the components of the card - both hardware, firmware (running and flashed). Driver authors can choose descriptive identifiers for the version fields. A few version identifiers which seemed relevant for most devices have been added to the global devlink header. Example: $ devlink dev info pci/0000:05:00.0 pci/0000:05:00.0: driver nfp serial_number 16240145 versions: fixed: board.id AMDA0099-0001 board.rev 07 board.vendor SMA board.model carbon running: fw.mgmt: 010156.010156.010156 fw.cpld: 0x44 fw.app: sriov-2.1.16 stored: fw.mgmt: 010158.010158.010158 fw.cpld: 0x44 fw.app: sriov-2.1.20 Last patch also includes a compat code for ethtool. If driver reports no fw_version via the traditional ethtool API, ethtool can call into devlink and try to cram as many versions as possible into the 31 characters. v4: - use IS_REACHABLE instead of IS_ENABLED in last patch. v3 (Jiri): - rename various functions and attributes; - break out the version helpers per-type; - make the compat code parse a dump instead of special casing in each helper; - move generic version defines to a separate patch. v2: - rebase. this non-RFC, v3 some would say: - add three more versions in the NFP patches; - add last patch (ethool compat) - Andrew & Michal. RFCv2: - use one driver op; - allow longer serial number; - wrap the skb into an opaque request struct; - add some common identifier into the devlink header. ==================== Signed-off-by: -
Jakub Kicinski authored
If driver did not fill the fw_version field, try to call into the new devlink get_info op and collect the versions that way. We assume ethtool was always reporting running versions. v4: - use IS_REACHABLE() to avoid problems with DEVLINK=m (kbuildbot). v3 (Jiri): - do a dump and then parse it instead of special handling; - concatenate all versions (well, all that fit :)). Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Jakub Kicinski authored
Report versions of firmware components using the new NSP command. Signed-off-by:
-
Jakub Kicinski authored
Retrieve the FW versions with the new command. Signed-off-by:
-
Jakub Kicinski authored
Report information about the hardware. RFCv2: - add defines for board IDs which are likely to be reusable for other drivers (Jiri). Signed-off-by:
-
Jakub Kicinski authored
Report the basic info through new devlink info API. RFCv2: - add driver name; - align serial to core changes. Signed-off-by:
-
Jakub Kicinski authored
Add defines and docs for generic info versions. v3: - add docs; - separate patch (Jiri). Signed-off-by:
-
Jakub Kicinski authored
ethtool -i has a few fixed-size fields which can be used to report firmware version and expansion ROM version. Unfortunately, modern hardware has more firmware components. There is usually some datapath microcode, management controller, PXE drivers, and a CPLD load. Running ethtool -i on modern controllers reveals the fact that vendors cram multiple values into firmware version field. Here are some examples from systems I could lay my hands on quickly: tg3: "FFV20.2.17 bc 5720-v1.39" i40e: "6.01 0x800034a4 1.1747.0" nfp: "0.0.3.5 0.25 sriov-2.1.16 nic" Add a new devlink API to allow retrieving multiple versions, and provide user-readable name for those versions. While at it break down the versions into three categories: - fixed - this is the board/fixed component version, usually vendors report information like the board version in the PCI VPD, but it will benefit from naming and common API as well; - running - this is the running firmware version; - stored - this is firmware in the flash, after firmware update this value will reflect the flashed version, while the running version may only be updated after reboot. v3: - add per-type helpers instead of using the special argument (Jiri). RFCv2: - remove the nesting in attr DEVLINK_ATTR_INFO_VERSIONS (now versions are mixed with other info attrs)l - have the driver report versions from the same callback as other info. Signed-off-by: -
Jakub Kicinski authored
ethtool -i has served us well for a long time, but its showing its limitations more and more. The device information should also be reported per device not per-netdev. Lay foundation for a simple devlink-based way of reading device info. Add driver name and device serial number as initial pieces of information exposed via this new API. v3: - rename helpers (Jiri); - rename driver name attr (Jiri); - remove double spacing in commit message (Jiri). RFC v2: - wrap the skb into an opaque structure (Jiri); - allow the serial number of be any length (Jiri & Andrew); - add driver name (Jonathan). Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== selftests: Various fixes This patch set contains various fixes whose common denominator is improving quality of forwarding and mlxsw selftests. Most of the fixes are improvements in determinism (such that timing and latency don't impact the test performance). These were prompted by regular runs of the test suite on a hardware emulator, the performance of which is necessarily lower than that of the real device. Patches #1 (from Ido), #2 and #3 make changes to ping limits. Patches #4 and #5 add more sleep in places where things need more time to finish. Patches #6 and #7 fix two tests in the suite of mirror-to-gretap tests where underlay involves a VLAN device over an 802.1q bridge. Patches #8, #9 and #10 fix bugs in mirror-to-gretap test where underlay involves a LAG device. Patch #11 fixes a missed RET initialization in mirror-to-gretap flower test. ==================== Signed-off-by: -
Petr Machata authored
The global variable RET needs to be initialized before each call to log_test. This test case sets it once before running the tests, but then calls log_tests for every individual test. Thus a failure in one of the tests causes spurious failures in follow-up tests as well. Fix by moving the initialization of RET from test_all() to full_test_span_gre_dir_acl(), a function that implements the test. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Petr Machata authored
This test sets up mirroring such that it mirrors all overlay traffic. That includes ARP, which causes occasional miscounts and spurious failures. Ignore ARP explicitly to avoid these problems. Signed-off-by:
-
Petr Machata authored
This test relies on routing in the primary traffic path, but neglects to enable forwarding. Do so. Signed-off-by:
-
Petr Machata authored
After one LAG slave is downed and another upped, it takes a while for the neighbor on a bridge to time out and get renegotiated. The test does prompt update of FDB entries by arpinging. But because the neighbor still references another address, offloading is not possible, and some packets may end up not being mirrored. To force the neighbor renegotiation, simply flush the neighbor table at the bridge. Signed-off-by:
-
Petr Machata authored
ARP or ND traffic can cause spurious migration of FDB back to $swp3. Mirroring is then updated in accordance with the change, and mirrored packets are seen at h3, causing a failure. Detect the case of this spurious roaming, and retry the test. Signed-off-by:
-
Petr Machata authored
The untagged egress test sets up mirroring to {,ip6}gretap such that the underlay goes through a bridge. Then VLAN flags are manipulated to test that the traffic leaves the bridge 802.1q-tagged or not, as appropriate. However, when a neighbor expires at the time that the bridge VLAN is configured as PVID and egress untagged, the following discovery process can't finish, because the IP address on H3 is still at the VLAN-tagged netdevice. This manifests by occasional failures where only several of the 10 required packets get through. Therefore, when reconfiguring the VLAN flags, move the IP address to the appropriate device in the H3 VRF. In addition to that, take this opportunity to embed an ASCII art diagram to make the topology move obvious. Signed-off-by: -
Petr Machata authored
When running in an environment with poor performance (such as a simulator), processing mirrored packets can take a while. Evaluating the condition too soon leads to spurious "seen 9, expected 10" failures as the last packet doesn't have enough time to get mirrored and the mirror to arrive and bump the observed counters. Wait for one ping interval before evaluating the test. Signed-off-by:
-
Petr Machata authored
When running in a simulator, the TTL change takes a while to settle and during this time the performance of the packet processing is lowered. The resulting instability leads to ping sending more packets as it assumes some have been dropped. This then leads to regular spurious failures as more packets than expected are observed. Sleep a bit to give the system time to stabilize. Signed-off-by:
-
Petr Machata authored
The current ping intervals are too short for running mirroring tests in simulator. This leads to ping sending a follow-up ping before the reply arrives, thus sending more than the requested 10 ICMP requests. This traffic is seen at the counters, and causes spurious failures. Bump interval and timeout numbers 5x in mirroring tests to address the spurious failures. Signed-off-by:
-
Petr Machata authored
The current ping intervals are too short for running mirroring tests in simulator. This leads to ping sending a follow-up ping before the reply arrives, thus sending more than the requested 10 ICMP requests. Those are mirrored, and over a certain threshold the test case run is considered a failure, because too much traffic is observed. Bump interval and timeout numbers 5x in mirroring tests to address the spurious failures. Signed-off-by:
-
Ido Schimmel authored
The current timeout (2 seconds) proved to be too low for some (emulated) systems where we run the tests. Make the timeout configurable and default to 5 seconds. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Martin Kepplinger authored
commit 3fb72f1e ("ipconfig wait for carrier") added a "wait for carrier" policy, with a fixed worst case maximum wait of two minutes. Now make the wait for carrier timeout configurable on the kernel commandline and use the 120s as the default. The timeout messages introduced with commit 5e404cd6 ("ipconfig: add informative timeout messages while waiting for carrier") are done in a fixed interval of 20 seconds, just like they were before (240/12). Signed-off-by:
Martin Kepplinger <martin.kepplinger@ginzinger.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: -
Dave Watson authored
Currently we don't zerocopy if the crypto framework async bit is set. However some crypto algorithms (such as x86 AESNI) support async, but in the context of sendmsg, will never run asynchronously. Instead, check for actual EINPROGRESS return code before assuming algorithm is async. Signed-off-by:
Dave Watson <davejwatson@fb.com> Signed-off-by:
-
David S. Miller authored
Dave Watson says: ==================== net: tls: TLS 1.3 support This patchset adds 256bit keys and TLS1.3 support to the kernel TLS socket. TLS 1.3 is requested by passing TLS_1_3_VERSION in the setsockopt call, which changes the framing as required for TLS1.3. 256bit keys are requested by passing TLS_CIPHER_AES_GCM_256 in the sockopt. This is a fairly straightforward passthrough to the crypto framework. 256bit keys work with both TLS 1.2 and TLS 1.3 TLS 1.3 requires a different AAD layout, necessitating some minor refactoring. It also moves the message type byte to the encrypted portion of the message, instead of the cleartext header as it was in TLS1.2. This requires moving the control message handling to after decryption, but is otherwise similar. V1 -> V2 The first two patches were dropped, and sent separately, one as a bugfix to the net tree. ==================== Signed-off-by: -
Dave Watson authored
Change most tests to TLS 1.3, while adding tests for previous TLS 1.2 behavior. Signed-off-by:
-
Dave Watson authored
TLS 1.3 has minor changes from TLS 1.2 at the record layer. * Header now hardcodes the same version and application content type in the header. * The real content type is appended after the data, before encryption (or after decryption). * The IV is xored with the sequence number, instead of concatinating four bytes of IV with the explicit IV. * Zero-padding: No exlicit length is given, we search backwards from the end of the decrypted data for the first non-zero byte, which is the content type. Currently recv supports reading zero-padding, but there is no way for send to add zero padding. Signed-off-by:
-
Dave Watson authored
For TLS 1.3, the control message is encrypted. Handle control message checks after decryption. Signed-off-by:
-
Dave Watson authored
TLS 1.3 has a different AAD size, use a variable in the code to make TLS 1.3 support easy. Signed-off-by:
-
Dave Watson authored
Wire up support for 256 bit keys from the setsockopt to the crypto framework Signed-off-by:
-
Daniel Borkmann authored
Maciej Fijalkowski says: ==================== This patchset tries to address the situation where: * user loads a particular xdp sample application that does stats polling * user loads another sample application on the same interface * then, user sends SIGINT/SIGTERM to the app that was attached as a first one * second application ends up with an unloaded xdp program 1st patch contains a helper libbpf function for getting the map fd by a given map name. In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu which was a blocker for converting this sample to libbpf usage. 3rd patch updates a bunch of xdp samples to make the use of libbpf. Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset. In patch 5 extack messages are added for cases where dev_change_xdp_fd returns with an error so user has an idea what was the reason for not attaching the xdp program onto interface. Patch 6 makes the samples behavior similar to what iproute2 does when loading xdp prog - the "force" flag is introduced. Patch 7 introduces the libbpf function that will query the driver from userspace about the currently attached xdp prog id. Use it in samples that do polling by checking the prog id in signal handler and comparing it with previously stored one which is the scope of patch 8. Thanks! v1->v2: * add a libbpf helper for getting a prog via relative index * include xdp_redirect_cpu into conversion v2->v3: mostly addressing Daniel's/Jesper's comments * get rid of the helper from v1->v2 * feed the xdp_redirect_cpu with program name instead of number v3->v4: * fix help message in xdp_sample_pkts v4->v5: * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned with 0 * add extack messages in dev_change_xdp_fd * check the return value of bpf_get_link_xdp_id when exiting from sample progs v5->v6: * rebase ==================== Signed-off-by:Daniel Borkmann <daniel@iogearbox.net>
-
