- 28 Aug, 2023 40 commits
-
-
Daniel Borkmann authored
Fix a memory leak for the tc egress path with TC_ACT_{STOLEN,QUEUED,TRAP}: [...] unreferenced object 0xffff88818bcb4f00 (size 232): comm "softirq", pid 0, jiffies 4299085078 (age 134.028s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 80 70 61 81 88 ff ff 00 41 31 14 81 88 ff ff ..pa.....A1..... backtrace: [<ffffffff9991b938>] kmem_cache_alloc_node+0x268/0x400 [<ffffffff9b3d9231>] __alloc_skb+0x211/0x2c0 [<ffffffff9b3f0c7e>] alloc_skb_with_frags+0xbe/0x6b0 [<ffffffff9b3bf9a9>] sock_alloc_send_pskb+0x6a9/0x870 [<ffffffff9b6b3f00>] __ip_append_data+0x14d0/0x3bf0 [<ffffffff9b6ba24e>] ip_append_data+0xee/0x190 [<ffffffff9b7e1496>] icmp_push_reply+0xa6/0x470 [<ffffffff9b7e4030>] icmp_reply+0x900/0xa00 [<ffffffff9b7e42e3>] icmp_echo.part.0+0x1a3/0x230 [<ffffffff9b7e444d>] icmp_echo+0xcd/0x190 [<ffffffff9b7e9566>] icmp_rcv+0x806/0xe10 [<ffffffff9b699bd1>] ip_protocol_deliver_rcu+0x351/0x3d0 [<ffffffff9b699f14>] ip_local_deliver_finish+0x2b4/0x450 [<ffffffff9b69a234>] ip_local_deliver+0x174/0x1f0 [<ffffffff9b69a4b2>] ip_sublist_rcv_finish+0x1f2/0x420 [<ffffffff9b69ab56>] ip_sublist_rcv+0x466/0x920 [...] I was able to reproduce this via: ip link add dev dummy0 type dummy ip link set dev dummy0 up tc qdisc add dev eth0 clsact tc filter add dev eth0 egress protocol ip prio 1 u32 match ip protocol 1 0xff action mirred egress redirect dev dummy0 ping 1.1.1.1 <stolen> After the fix, there are no kmemleak reports with the reproducer. This is in line with what is also done on the ingress side, and from debugging the skb_unref(skb) on dummy xmit and sch_handle_egress() side, it is visible that these are two different skbs with both skb_unref(skb) as true. The two seen skbs are due to mirred doing a skb_clone() internally as use_reinsert is false in tcf_mirred_act() for egress. This was initially reported by Gal. Fixes: e420bed0 ("bpf: Add fd-based tcx multi-prog infra with link support") Reported-by:Gal Pressman <gal@nvidia.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/bdfc2640-8f65-5b56-4472-db8e2b161aab@nvidia.comReviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hariprasad Kelam says: ==================== octeontx2-af: misc MAC block changes This series of patches adds recent changes added in MAC (CGX/RPM) block. Patch1: Adds new LMAC mode supported by CN10KB silicon Patch2: In a scenario where system boots with no cgx devices, currently AF driver treats this as error as a result no interfaces will work. This patch relaxes this check, such that non cgx mapped netdev devices will work. Patch3: This patch adds required lmac validation in MAC block APIs. Patch4: Prints error message incase, no netdev is mapped with given cgx,lmac pair. ==================== Signed-off-by: -
Hariprasad Kelam authored
During AF driver initialization, it creates a mapping between pf to cgx,lmac pair. Whenever there is a physical link change, using this mapping driver forwards the message to the associated netdev. This patch prints error message incase of cgx,lmac pair is not associated with any pf netdev. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
With the addition of new MAC blocks like CN10K RPM and CN10KB RPM_USX, LMACs are noncontiguous. Though in most of the functions, lmac validation checks exist but in few functions they are missing. This patch adds the same. Signed-off-by:
-
Sunil Goutham authored
Don't treat lack of CGX LMACs on the system as a error. Instead ignore it so that LBK VFs are created and can be used. Signed-off-by:
-
Hariprasad Kelam authored
Upon physical link change, firmware reports to the kernel about the change along with the details like speed, lmac_type_id, etc. Kernel derives lmac_type based on lmac_type_id received from firmware. This patch extends current lmac list with new USGMII mode supported by CN10KB RPM block. Signed-off-by:
-
Pranavi Somisetty authored
Convert the Xilinx GMII to RGMII Converter device tree binding documentation to json schema. This converter is usually used as gem <---> gmii2rgmii <---> external phy and, it's phy-handle should point to the phandle of the external phy. Signed-off-by:
Pranavi Somisetty <pranavi.somisetty@amd.com> Signed-off-by:
Harini Katakam <harini.katakam@amd.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Jakub Kicinski authored
Sabrina Dubroca says: ==================== tls: expand tls_cipher_size_desc to simplify getsockopt/setsockopt Commit 2d2c5ea2 ("net/tls: Describe ciphers sizes by const structs") introduced tls_cipher_size_desc to describe the size of the fields of the per-cipher crypto_info structs, and commit ea7a9d88 ("net/tls: Use cipher sizes structs") used it, but only in tls_device.c and tls_device_fallback.c, and skipped converting similar code in tls_main.c and tls_sw.c. This series expands tls_cipher_size_desc (renamed to tls_cipher_desc to better fit this expansion) to fully describe a cipher: - offset of the fields within the per-cipher crypto_info - size of the full struct (for copies to/from userspace) - offload flag - algorithm name used by SW crypto With these additions, we can remove ~350L of switch (crypto_info->cipher_type) { ... } from tls_set_device_offload, tls_sw_fallback_init, do_tls_getsockopt_conf, do_tls_setsockopt_conf, tls_set_sw_offload (mainly do_tls_getsockopt_conf and tls_set_sw_offload). This series also adds the ARIA ciphers to the tls selftests, and some more getsockopt/setsockopt tests to cover more of the code changed by this series. ==================== Link: https://lore.kernel.org/r/cover.1692977948.git.sd@queasysnail.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Sabrina Dubroca authored
tls_cipher_desc also contains the algorithm name needed by crypto_alloc_aead, use it. Finally, use get_cipher_desc to check if the cipher_type coming from userspace is valid, and remove the cipher_type switch. Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/53d021d80138aa125a9cef4468aa5ce531975a7b.1692977948.git.sd@queasysnail.netSigned-off-by:
-
Sabrina Dubroca authored
The crypto_info_* helpers allow us to fetch pointers into the per-cipher crypto_info's data. Signed-off-by:
-
Sabrina Dubroca authored
We can get rid of some local variables, but we have to keep nonce_size because tls1.3 uses nonce_size = 0 for all ciphers. We can also drop the runtime sanity checks on iv/rec_seq/tag size, since we have compile time checks on those values. Signed-off-by:
-
Sabrina Dubroca authored
Every cipher uses the same code to update its crypto_info struct based on the values contained in the cctx, with only the struct type and size/offset changing. We can get those from tls_cipher_desc, and use a single pair of memcpy and final copy_to_user. Signed-off-by:
-
Sabrina Dubroca authored
We can simplify do_tls_setsockopt_conf using tls_cipher_desc. Also use get_cipher_desc's result to check if the cipher_type coming from userspace is valid. Signed-off-by:
-
Sabrina Dubroca authored
tls_sw_fallback_init already gets the key and tag size from tls_cipher_desc. We can now also check that the cipher type is valid, and stop hard-coding the algorithm name passed to crypto_alloc_aead. Signed-off-by:
-
Sabrina Dubroca authored
No need to allocate the aead if we're going to fail afterwards. Signed-off-by:
-
Sabrina Dubroca authored
tls_set_device_offload is already getting iv and rec_seq sizes from tls_cipher_desc. We can now also check if the cipher_type coming from userspace is valid and can be offloaded. We can also remove the runtime check on rec_seq, since we validate it at compile time. Signed-off-by:
-
Sabrina Dubroca authored
Signed-off-by:
-
Sabrina Dubroca authored
- add nonce, usually equal to iv_size but not for chacha - add offsets into the crypto_info for each field - add algorithm name - add offloadable flag Also add helpers to access each field of a crypto_info struct described by a tls_cipher_desc. Signed-off-by:
-
Sabrina Dubroca authored
We're going to add other fields to it to fully describe a cipher, so the "_size" name won't match the contents. Signed-off-by:
-
Sabrina Dubroca authored
tls_cipher_size_desc indexes ciphers by their type, but we're not using indices 0..50 of the array. Each struct tls_cipher_size_desc is 20B, so that's a lot of unused memory. We can reindex the array starting at the lowest used cipher_type. Introduce the get_cipher_size_desc helper to find the right item and avoid out-of-bounds accesses, and make tls_cipher_size_desc's size explicit so that gcc reminds us to update TLS_CIPHER_MIN/MAX when we add a new cipher. Signed-off-by:
-
Sabrina Dubroca authored
Signed-off-by:
-
Sabrina Dubroca authored
It's only used in net/tls/*, no need to bloat include/net/tls.h. Signed-off-by:
-
Sabrina Dubroca authored
This test will need to be updated if new ciphers are added. Signed-off-by:
-
Sabrina Dubroca authored
The kernel accepts fetching either just the version and cipher type, or exactly the per-cipher struct. Also check that getsockopt returns what we just passed to the kernel. Signed-off-by:
-
Sabrina Dubroca authored
Only supported for TLS1.2. Signed-off-by:
-
Jakub Kicinski authored
Donald Hunter says: ==================== tools/net/ynl: Add support for netlink-raw families This patchset adds support for netlink-raw families such as rtnetlink. Patch 1 fixes a typo in existing schemas Patch 2 contains the schema definition Patches 3 & 4 update the schema documentation Patches 5 - 9 extends ynl Patches 10 - 12 add several netlink-raw specs The netlink-raw schema is very similar to genetlink-legacy and I thought about making the changes there and symlinking to it. On balance I thought that might be problematic for accurate schema validation. rtnetlink doesn't seem to fit into unified or directional message enumeration models. It seems like an 'explicit' model would be useful, to force the schema author to specify the message ids directly. There is not yet support for notifications because ynl currently doesn't support defining 'event' properties on a 'do' operation. The message ids are shared so ops need to be both sync and async. I plan to look at this in a future patch. The link and route messages contain different nested attributes dependent on the type of link or route. Decoding these will need some kind of attr-space selection that uses the value of another attribute as the selector key. These nested attributes have been left with type 'binary' for now. ==================== Link: https://lore.kernel.org/r/20230825122756.7603-1-donald.hunter@gmail.comSigned-off-by:
-
Donald Hunter authored
Add schema for rt route with support for getroute, newroute and delroute. Routes can be dumped with filter attributes like this: ./tools/net/ynl/cli.py \ --spec Documentation/netlink/specs/rt_route.yaml \ --dump getroute --json '{"rtm-family": 2, "rtm-table": 254}' Signed-off-by:Donald Hunter <donald.hunter@gmail.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20230825122756.7603-13-donald.hunter@gmail.comSigned-off-by:
-
Donald Hunter authored
Add schema for rt link with support for newlink, dellink, getlink, setlink and getstats. A dummy link can be created like this: sudo ./tools/net/ynl/cli.py \ --spec Documentation/netlink/specs/rt_link.yaml \ --do newlink --create \ --json '{"ifname": "dummy0", "linkinfo": {"kind": "dummy"}}' For example, offload stats can be fetched like this: ./tools/net/ynl/cli.py \ --spec Documentation/netlink/specs/rt_link.yaml \ --dump getstats --json '{ "filter-mask": 8 }' Signed-off-by: -
Donald Hunter authored
Add schema for rt addr with support for: - newaddr, deladdr, getaddr (dump) Signed-off-by: -
Donald Hunter authored
Add support for using NLM_F_REPLACE, _EXCL, _CREATE and _APPEND flags in requests. Signed-off-by:
-
Donald Hunter authored
Add support for the 'array-nest' attribute type that is used by several netlink-raw families. Signed-off-by:
-
Donald Hunter authored
Refactor the ynl code to encapsulate protocol specifics into NetlinkProtocol and GenlProtocol. Signed-off-by:
-
Donald Hunter authored
Move decode_fixed_header into YnlFamily and add a _fixed_header_size method to allow extack decoding to skip the fixed header. Signed-off-by:
-
Donald Hunter authored
Add a SpecMcastGroup class to the nlspec lib. Signed-off-by:
-
Donald Hunter authored
Add a doc page for netlink-raw that describes the schema attributes needed for netlink-raw. Signed-off-by:
-
Donald Hunter authored
Add documentation for recently added genetlink-legacy schema attributes. Remove statements about 'work in progress' and 'todo'. Signed-off-by:
-
Donald Hunter authored
This schema is largely a copy of the genetlink-legacy schema with the following modifications: - change the schema id to netlink-raw - add a top-level protonum property, e.g. 0 (for NETLINK_ROUTE) - change the protocol enumeration to netlink-raw, removing the genetlink options. - replace doc references to generic netlink with raw netlink - add a value property to mcast-group definitions Signed-off-by:
-
Donald Hunter authored
Fix typo verion -> version in genetlink-c and genetlink-legacy. Signed-off-by:
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== {devlink,mlx5}: Add port function attributes for ipsec From Dima: Introduce hypervisor-level control knobs to set the functionality of PCI VF devices passed through to guests. The administrator of a hypervisor host may choose to change the settings of a port function from the defaults configured by the device firmware. The software stack has two types of IPsec offload - crypto and packet. Specifically, the ip xfrm command has sub-commands for "state" and "policy" that have an "offload" parameter. With ip xfrm state, both crypto and packet offload types are supported, while ip xfrm policy can only be offloaded in packet mode. The series introduces two new boolean attributes of a port function: ipsec_crypto and ipsec_packet. The goal is to provide a similar level of granularity for controlling VF IPsec offload capabilities, which would be aligned with the software model. This will allow users to decide if they want both types of offload enabled for a VF, just one of them, or none at all (which is the default). At a high level, the difference between the two knobs is that with ipsec_crypto, only XFRM state can be offloaded. Specifically, only the crypto operation (Encrypt/Decrypt) is offloaded. With ipsec_packet, both XFRM state and policy can be offloaded. Furthermore, in addition to crypto operation offload, IPsec encapsulation is also offloaded. For XFRM state, choosing between crypto and packet offload types is possible. From the HW perspective, different resources may be required for each offload type. Examples of when a user prefers to enable IPsec packet offload for a VF when using switchdev mode: $ devlink port show pci/0000:06:00.0/1 pci/0000:06:00.0/1: type eth netdev enp6s0pf0vf0 flavour pcivf pfnum 0 vfnum 0 function: hw_addr 00:00:00:00:00:00 roce enable migratable disable ipsec_crypto disable ipsec_packet disable $ devlink port function set pci/0000:06:00.0/1 ipsec_packet enable $ devlink port show pci/0000:06:00.0/1 pci/0000:06:00.0/1: type eth netdev enp6s0pf0vf0 flavour pcivf pfnum 0 vfnum 0 function: hw_addr 00:00:00:00:00:00 roce enable migratable disable ipsec_crypto disable ipsec_packet enable This enables the corresponding IPsec capability of the function before it's enumerated, so when the driver reads the capability from the device firmware, it is enabled. The driver is then able to configure corresponding features and ops of the VF net device to support IPsec state and policy offloading. v2: https://lore.kernel.org/netdev/20230421104901.897946-1-dchumak@nvidia.com/ ==================== Link: https://lore.kernel.org/r/20230825062836.103744-1-saeed@kernel.orgSigned-off-by: -
Dima Chumak authored
Implement devlink port function commands to enable / disable IPsec packet offloads. This is used to control the IPsec capability of the device. When ipsec_offload is enabled for a VF, it prevents adding IPsec packet offloads on the PF, because the two cannot be active simultaneously due to HW constraints. Conversely, if there are any active IPsec packet offloads on the PF, it's not allowed to enable ipsec_packet on a VF, until PF IPsec offloads are cleared. Signed-off-by:
Dima Chumak <dchumak@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20230825062836.103744-9-saeed@kernel.orgSigned-off-by:
-
