- 27 Jan, 2023 18 commits
-
-
Alex Elder authored
The packet length encoded in an IPA packet status buffer is computed more than once in ipa_endpoint_status_parse(). It is also checked again in ipa_endpoint_status_skip(), which that function calls. Compute the length once, and use that computed value later rather than recomputing it. Check for it being zero in the parse function rather than in ipa_endpoint_status_skip(). Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The build system currently complains: scripts/Makefile.build:252: drivers/net/dsa/ocelot/Makefile: felix.o is added to multiple modules: mscc_felix mscc_seville Since felix.c holds the DSA glue layer, create a mscc_felix_dsa_lib.ko. This is similar to how mscc_ocelot_switch_lib.ko holds a library for configuring the hardware. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20230125145716.271355-1-vladimir.oltean@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== virtchnl: update and refactor Jesse Brandeburg says: The virtchnl.h file is used by i40e/ice physical function (PF) drivers and irdma when talking to the iavf driver. This series cleans up the header file by removing unused elements, adding/cleaning some comments, fixing the data structures so they are explicitly defined, including padding, and finally does a long overdue rename of the IWARP members in the structures to RDMA, since the ice driver and it's associated Intel Ethernet E800 series adapters support both RDMA and IWARP. The whole series should result in no functional change, but hopefully clearer code. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: virtchnl: i40e/iavf: rename iwarp to rdma virtchnl: do structure hardening virtchnl: update header and increase header clarity virtchnl: remove unused structure declaration ==================== Link: https://lore.kernel.org/r/20230125212441.4030014-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== tools: ynl: prevent reorder and fix flags Some codegen improvements for YAML specs. First, Lorenzon discovered when switching the XDP feature family to use flags instead of pure enum that the kdoc got garbled. The support for enum and flags is therefore unified. Second when regenerating all families we discussed so far I noticed that some netlink policies jumped around. We need to ensure we don't render code based on their ordering in a hash. ==================== Link: https://lore.kernel.org/r/20230126000235.1085551-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
When rendering code we should walk the ops in the order in which they are declared in the spec. This is both more intuitive and prevents code from jumping around when hashing in the dict changes. Signed-off-by: -
Jakub Kicinski authored
ops_list contains all the operations, but the main iteration use case is to walk only ops which define attrs. Rename ops_list to msg_list, because now it looks like the contents are the same, just the format is different. While at it convert from tuple to just keys, none of the users care about the name of the op. Signed-off-by: -
Jakub Kicinski authored
Lorenzo reports that after switching from enum to flags netdev family lost ability to render kdoc (and the enum contents got generally garbled). Combine the flags and enum handling in uAPI handling. Reported-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
Leon Romanovsky says: ==================== Convert drivers to return XFRM configuration errors through extack This series continues effort started by Sabrina to return XFRM configuration errors through extack. It allows for user space software stack easily present driver failure reasons to users. As a note, Intel drivers have a path where extack is equal to NULL, and error prints won't be available in current patchset. If it is needed, it can be changed by adding special to Intel macro to print to dmesg in case of extack == NULL. ==================== Link: https://lore.kernel.org/r/cover.1674560845.git.leon@kernel.orgSigned-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Almost all validation logic is in the drivers, but they are missing reliable way to convey failure reason to userspace applications. Let's use extack to return this information to users. Signed-off-by:
-
Leon Romanovsky authored
Rely on extack to return failure reason. Signed-off-by:
-
Leon Romanovsky authored
Almost all validation logic is in the drivers, but they are missing reliable way to convey failure reason to userspace applications. Let's use extack to return this information to users. Signed-off-by:
-
- 26 Jan, 2023 22 commits
-
-
Vladimir Oltean authored
ethtool_aggregate_*_stats() are implemented in net/ethtool/stats.c, a file which is compiled out when CONFIG_ETHTOOL_NETLINK=n. In order to avoid adding Kbuild dependencies from drivers (which call these helpers) on CONFIG_ETHTOOL_NETLINK, let's add some shim definitions which simply make the helpers dead code. This means the function prototypes should have been located in include/linux/ethtool_netlink.h rather than include/linux/ethtool.h. Fixes: 449c5459 ("net: ethtool: add helpers for aggregate statistics") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Matthieu Baerts says: ==================== mptcp: add mixed v4/v6 support for the in-kernel PM Before these patches, the in-kernel Path-Manager would not allow, for the same MPTCP connection, having a mix of subflows in v4 and v6. MPTCP's RFC 8684 doesn't forbid that and it is even recommended to do so as the path in v4 and v6 are likely different. Some networks are also v4 or v6 only, we cannot assume they all have both v4 and v6 support. Patch 1 then removes this artificial constraint in the in-kernel PM currently enforcing there are no mixed subflows in place, either in address announcement or in subflow creation areas. Patch 2 makes sure the sk_ipv6only attribute is also propagated to subflows, just in case a new PM wouldn't respect it. Some selftests have also been added for the in-kernel PM (patch 3). Patches 4 to 8 are just some cleanups and small improvements in the printed messages in the userspace PM. It is not linked to the rest but identified when working on a related patch modifying this selftest, already in -net: commit 4656d72c ("selftests: mptcp: userspace: validate v4-v6 subflows mix") --- ==================== Link: https://lore.kernel.org/r/20230123-upstream-net-next-pm-v4-v6-v1-0-43fac502bfbf@tessares.netSigned-off-by:
-
Matthieu Baerts authored
During the cleanup phase, the server pids were killed with a SIGTERM directly, not using a SIGUSR1 first to quit safely. As a result, this test was often ending with two error messages: read: Connection reset by peer While at it, use a for-loop to terminate all the PIDs the same way. Also the different files are now removed after having killed the PIDs using them. It makes more sense to do that in this order. Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Matthieu Baerts authored
Before, only '[FAIL]' was printed in case of error during the validation phase. Now, in case of failure, the variable name, its value and expected one are displayed to help understand what was wrong. Reviewed-by:
-
Matthieu Baerts authored
Instead of having a long list of conditions to check, it is possible to give a list of variable names to compare with their 'e_XXX' version. This will ease the introduction of the following commit which will print which condition has failed (if any). Reviewed-by:
-
Matthieu Baerts authored
This script is running a few tests after having setup the environment. Printing titles helps understand what is being tested. Reviewed-by:
-
Matthieu Baerts authored
Like in all other functions in this file, a single point of exit is used when extra operations are needed: unlock, decrement refcount, etc. There is no functional change for the moment but it is better to do the same here to make sure all cleanups are done in case of intermediate errors. Reviewed-by:
-
Paolo Abeni authored
Note that we can't guess the listener family anymore based on the client target address: always use IPv6. The fullmesh flag with endpoints from different families is also validated here. Signed-off-by:
-
Matthieu Baerts authored
Usually, attributes are propagated to subflows as well. Here, if subflows are created by other ways than the MPTCP path-manager, it is important to make sure they are in v6 if it is asked by the userspace. Reviewed-by:
-
Paolo Abeni authored
Currently the in-kernel PM arbitrary enforces that created subflow's family must match the main MPTCP socket while the RFC allows mixing IPv4 and IPv6 subflows. This patch changes the in-kernel PM logic to create subflows matching the currently selected source (or destination) address. IPv4 sockets can pick only IPv4 addresses (and v4 mapped in v6), while IPv6 sockets not restricted to V6ONLY can pick either IPv4 and IPv6 addresses as long as the source and destination matches. A helper, previously introduced is used to ease family matching checks, taking care of IPv4 vs IPv4-mapped-IPv6 vs IPv6 only addresses. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/269Co-developed-by:
-
Jamie Bainbridge authored
There are multiple ICMP rate limiting mechanisms: * Global limits: net.ipv4.icmp_msgs_burst/icmp_msgs_per_sec * v4 per-host limits: net.ipv4.icmp_ratelimit/ratemask * v6 per-host limits: net.ipv6.icmp_ratelimit/ratemask However, when ICMP output is limited, there is no way to tell which limit has been hit or even if the limits are responsible for the lack of ICMP output. Add counters for each of the cases above. As we are within local_bh_disable(), use the __INC stats variant. Example output: # nstat -sz "*RateLimit*" IcmpOutRateLimitGlobal 134 0.0 IcmpOutRateLimitHost 770 0.0 Icmp6OutRateLimitHost 84 0.0 Signed-off-by:
Jamie Bainbridge <jamie.bainbridge@gmail.com> Suggested-by:
Abhishek Rawal <rawal.abhishek92@gmail.com> Link: https://lore.kernel.org/r/273b32241e6b7fdc5c609e6f5ebc68caf3994342.1674605770.git.jamie.bainbridge@gmail.comSigned-off-by:
-
Paolo Abeni authored
Steen Hegelund says: ==================== Adding Sparx5 IS0 VCAP support This provides the Ingress Stage 0 (IS0) VCAP (Versatile Content-Aware Processor) support for the Sparx5 platform. The IS0 VCAP (also known in the datasheet as CLM) is a classifier VCAP that mainly extracts frame information to metadata that follows the frame in the Sparx5 processing flow all the way to the egress port. The IS0 VCAP has 4 lookups and they are accessible with a TC chain id: - chain 1000000: IS0 Lookup 0 - chain 1100000: IS0 Lookup 1 - chain 1200000: IS0 Lookup 2 - chain 1300000: IS0 Lookup 3 - chain 1400000: IS0 Lookup 4 - chain 1500000: IS0 Lookup 5 Each of these lookups have their own port keyset configuration that decides which keys will be used for matching on which traffic type. The IS0 VCAP has these traffic classifications: - IPv4 frames - IPv6 frames - Unicast MPLS frames (ethertype = 0x8847) - Multicast MPLS frames (ethertype = 0x8847) - Other frame types than MPLS, IPv4 and IPv6 The IS0 VCAP has an action that allows setting the value of a PAG (Policy Association Group) key field in the frame metadata, and this can be used for matching in an IS2 VCAP rule. This allow rules in the IS0 VCAP to be linked to rules in the IS2 VCAP. The linking is exposed by using the TC "goto chain" action with an offset from the IS2 chain ids. As an example a "goto chain 8000001" will use a PAG value of 1 to chain to a rule in IS2 Lookup 0. ==================== Link: https://lore.kernel.org/r/20230124104511.293938-1-steen.hegelund@microchip.comSigned-off-by:
-
Steen Hegelund authored
This adds support for parsing and matching on the CVLAN tags in the Sparx5 IS0 VCAP. Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
-
Steen Hegelund authored
This allows the IS0 VCAP to have its own list of supported ethernet protocol types matching what is supported by the VCAPs port lookup classification. Signed-off-by:
-
Steen Hegelund authored
With more than one possible actionset in a VCAP instance, the VCAP API will now use the actions in a VCAP rule to select the actionset that fits these actions the best possible way. Signed-off-by:
-
Steen Hegelund authored
This allows rules to be chained between VCAP instances, e.g. from IS0 Lookup 0 to IS0 Lookup 1, or from one of the IS0 Lookups to one of the IS2 Lookups. Chaining from an IS2 Lookup to another IS2 Lookup is not supported in the hardware. Signed-off-by:
-
Steen Hegelund authored
This enables the TC command to use the Sparx5 IS0 VCAP Signed-off-by:
-
Steen Hegelund authored
This adds the actionset type id to the rule information. This is needed as we now have more than one actionset in a VCAP instance (IS0). Signed-off-by:
-
Steen Hegelund authored
This adds the IS0 VCAP port keyset configuration for Sparx5 and also updates the debugFS support to show the keyset configuration. Signed-off-by:
-
Steen Hegelund authored
This provides the IS0 (Ingress Stage 0) or CLM VCAP model for Sparx5. This VCAP provides classification actions for Sparx5. Signed-off-by:
-
Jakub Kicinski authored
Jakub Sitnicki says: ==================== Add IP_LOCAL_PORT_RANGE socket option This patch set is a follow up to the "How to share IPv4 addresses by partitioning the port space" talk given at LPC 2022 [1]. Please see patch #1 for the motivation & the use case description. Patch #2 adds tests exercising the new option in various scenarios. Documentation ------------- Proposed update to the ip(7) man-page: IP_LOCAL_PORT_RANGE (since Linux X.Y) Set or get the per-socket default local port range. This option can be used to clamp down the global local port range, defined by the ip_local_port_range /proc interface described below, for a given socket. The option takes an uint32_t value with the high 16 bits set to the upper range bound, and the low 16 bits set to the lower range bound. Range bounds are inclusive. The 16-bit values should be in host byte order. The lower bound has to be less than the upper bound when both bounds are not zero. Otherwise, setting the option fails with EINVAL. If either bound is outside of the global local port range, or is zero, then that bound has no effect. To reset the setting, pass zero as both the upper and the lower bound. Interaction with SELinux bind() hook ------------------------------------ SELinux bind() hook - selinux_socket_bind() - performs a permission check if the requested local port number lies outside of the netns ephemeral port range. The proposed socket option cannot be used change the ephemeral port range to extend beyond the per-netns port range, as set by net.ipv4.ip_local_port_range. Hence, there is no interaction with SELinux, AFAICT. RFC -> v1 RFC: https://lore.kernel.org/netdev/20220912225308.93659-1-jakub@cloudflare.com/ * Allow either the high bound or the low bound, or both, to be zero * Add getsockopt support * Add selftests Links: ------ [1]: https://lpc.events/event/16/contributions/1349/ ==================== Link: https://lore.kernel.org/r/20221221-sockopt-port-range-v6-0-be255cc0e51f@cloudflare.comSigned-off-by: -
Jakub Sitnicki authored
Exercise IP_LOCAL_PORT_RANGE socket option in various scenarios: 1. pass invalid values to setsockopt 2. pass a range outside of the per-netns port range 3. configure a single-port range 4. exhaust a configured multi-port range 5. check interaction with late-bind (IP_BIND_ADDRESS_NO_PORT) 6. set then get the per-socket port range Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
-
