- 24 Aug, 2024 1 commit
-
-
Mina Almasry authored
When net devices propagate xdp configurations to slave devices, we will need to perform a memory provider check to ensure we're not binding xdp to a device using unreadable netmem. Currently the ->ndo_bpf calls in a few places. Adding checks to all these places would not be ideal. Refactor all the ->ndo_bpf calls into one place where we can add this check in the future. Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Mina Almasry <almasrymina@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 23 Aug, 2024 27 commits
-
-
David S. Miller authored
Li Zetao says: ==================== net: Delete some redundant judgments This patchset aims to remove some unnecessary judgments and make the code more concise. In some network modules, rtnl_set_sk_err is used to record error information, but the err is repeatedly judged to be less than 0 on the error path. Deleted these redundant judgments. No functional change intended. ==================== Signed-off-by: -
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
Li Zetao <lizetao1@huawei.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOMEM, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
Li Zetao authored
The initial value of err is -ENOBUFS, and err is guaranteed to be less than 0 before all goto errout. Therefore, on the error path of errout, there is no need to repeatedly judge that err is less than 0, and delete redundant judgments to make the code more concise. Signed-off-by:
-
David S. Miller authored
Maxime Chevallier says: ==================== Introduce PHY listing and link_topology tracking This is V18 of the phy_link_topology series, aiming at improving support for multiple PHYs being attached to the same MAC. V18 is a simple rebase of the V17 on top of net-next, gathering the tested-by and reviewed-by tags from Christophe (thanks !). This iteration is also one patch shorter than V17 (patch 12/14 in V17 is gone), as one of the patches used to fix an issue that has now been resolved by Simon Horman in 743ff021 ethtool: Don't check for NULL info in prepare_data callbacks As a remainder, here's what the PHY listings would look like : - eth0 has a 88x3310 acting as media converter, and an SFP module with an embedded 88e1111 PHY - eth2 has a 88e1510 PHY PHY for eth0: PHY index: 1 Driver name: mv88x3310 PHY device name: f212a600.mdio-mii:00 Downstream SFP bus name: sfp-eth0 Upstream type: MAC PHY for eth0: PHY index: 2 Driver name: Marvell 88E1111 PHY device name: i2c:sfp-eth0:16 Upstream type: PHY Upstream PHY index: 1 Upstream SFP name: sfp-eth0 PHY for eth2: PHY index: 1 Driver name: Marvell 88E1510 PHY device name: f212a200.mdio-mii:00 Upstream type: MAC Ethtool patches : https://github.com/minimaxwell/ethtool/tree/mc/topo-v16 (this branch is compatible with this V18 series) Link to V17: https://lore.kernel.org/netdev/20240709063039.2909536-1-maxime.chevallier@bootlin.com/ Link to V16: https://lore.kernel.org/netdev/20240705132706.13588-1-maxime.chevallier@bootlin.com/ Link to V15: https://lore.kernel.org/netdev/20240703140806.271938-1-maxime.chevallier@bootlin.com/ Link to V14: https://lore.kernel.org/netdev/20240701131801.1227740-1-maxime.chevallier@bootlin.com/ Link to V13: https://lore.kernel.org/netdev/20240607071836.911403-1-maxime.chevallier@bootlin.com/ Link to v12: https://lore.kernel.org/netdev/20240605124920.720690-1-maxime.chevallier@bootlin.com/ Link to v11: https://lore.kernel.org/netdev/20240404093004.2552221-1-maxime.chevallier@bootlin.com/ Link to V10: https://lore.kernel.org/netdev/20240304151011.1610175-1-maxime.chevallier@bootlin.com/ Link to V9: https://lore.kernel.org/netdev/20240228114728.51861-1-maxime.chevallier@bootlin.com/ Link to V8: https://lore.kernel.org/netdev/20240220184217.3689988-1-maxime.chevallier@bootlin.com/ Link to V7: https://lore.kernel.org/netdev/20240213150431.1796171-1-maxime.chevallier@bootlin.com/ Link to V6: https://lore.kernel.org/netdev/20240126183851.2081418-1-maxime.chevallier@bootlin.com/ Link to V5: https://lore.kernel.org/netdev/20231221180047.1924733-1-maxime.chevallier@bootlin.com/ Link to V4: https://lore.kernel.org/netdev/20231215171237.1152563-1-maxime.chevallier@bootlin.com/ Link to V3: https://lore.kernel.org/netdev/20231201163704.1306431-1-maxime.chevallier@bootlin.com/ Link to V2: https://lore.kernel.org/netdev/20231117162323.626979-1-maxime.chevallier@bootlin.com/ Link to V1: https://lore.kernel.org/netdev/20230907092407.647139-1-maxime.chevallier@bootlin.com/ More discussions on specific issues that happened in 6.9-rc: https://lore.kernel.org/netdev/20240412104615.3779632-1-maxime.chevallier@bootlin.com/ https://lore.kernel.org/netdev/20240429131008.439231-1-maxime.chevallier@bootlin.com/ https://lore.kernel.org/netdev/20240507102822.2023826-1-maxime.chevallier@bootlin.com/ ==================== Signed-off-by:
-
Maxime Chevallier authored
The newly introduced phy_link_topology tracks all ethernet PHYs that are attached to a netdevice. Document the base principle, internal and external APIs. As the phy_link_topology is expected to be extended, this documentation will hold any further improvements and additions made relative to topology handling. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by:
-
Maxime Chevallier authored
The ETH_SS_PHY_STATS command gets PHY statistics. Use the phydev pointer from the ethnl request to allow query phy stats from each PHY on the link. Signed-off-by:
-
Maxime Chevallier authored
Cable testing is a PHY-specific command. Instead of targeting the command towards dev->phydev, use the request to pick the targeted PHY. Signed-off-by:
-
Maxime Chevallier authored
PSE and PD configuration is a PHY-specific command. Instead of targeting the command towards dev->phydev, use the request to pick the targeted PHY device. As we don't get the PHY directly from the netdev's attached phydev, also adjust the error messages. Signed-off-by:
-
Maxime Chevallier authored
PLCA is a PHY-specific command. Instead of targeting the command towards dev->phydev, use the request to pick the targeted PHY. Signed-off-by:
-
Maxime Chevallier authored
The PHY_GET command, supporting both DUMP and GET operations, is used to retrieve the list of PHYs connected to a netdevice, and get topology information to know where exactly it sits on the physical link. Add the netlink specs corresponding to that command. Signed-off-by:
-
Maxime Chevallier authored
As we have the ability to track the PHYs connected to a net_device through the link_topology, we can expose this list to userspace. This allows userspace to use these identifiers for phy-specific commands and take the decision of which PHY to target by knowing the link topology. Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list devices on only one interface. Signed-off-by:
-
Maxime Chevallier authored
Update the spec to take the newly introduced phy-index as a generic request parameter. Signed-off-by:
-
Maxime Chevallier authored
Some netlink commands are target towards ethernet PHYs, to control some of their features. As there's several such commands, add the ability to pass a PHY index in the ethnl request, which will populate the generic ethnl_req_info with the passed phy_index. Add a helper that netlink command handlers need to use to grab the targeted PHY from the req_info. This helper needs to hold rtnl_lock() while interacting with the PHY, as it may be removed at any point. Signed-off-by:
-
Maxime Chevallier authored
Knowing the bus name is helpful when we want to expose the link topology to userspace, add a helper to return the SFP bus name. This call will always be made while holding the RTNL which ensures that the SFP driver won't unbind from the device. The returned pointer to the bus name will only be used while RTNL is held. Signed-off-by:
"Russell King (Oracle)" <linux@armlinux.org.uk> Reviewed-by:
-
Maxime Chevallier authored
There are a few PHY drivers that can handle SFP modules through their sfp_upstream_ops. Introduce Phylib helpers to keep track of connected SFP PHYs in a netdevice's namespace, by adding the SFP PHY to the upstream PHY's netdev's namespace. By doing so, these SFP PHYs can be enumerated and exposed to users, which will be able to use their capabilities. Signed-off-by:
-
Maxime Chevallier authored
Pass the phy_device as a parameter to the sfp upstream .disconnect_phy operation. This is preparatory work to help track phy devices across a net_device's link. Signed-off-by:
-
Maxime Chevallier authored
Link topologies containing multiple network PHYs attached to the same net_device can be found when using a PHY as a media converter for use with an SFP connector, on which an SFP transceiver containing a PHY can be used. With the current model, the transceiver's PHY can't be used for operations such as cable testing, timestamping, macsec offload, etc. The reason being that most of the logic for these configuration, coming from either ethtool netlink or ioctls tend to use netdev->phydev, which in multi-phy systems will reference the PHY closest to the MAC. Introduce a numbering scheme allowing to enumerate PHY devices that belong to any netdev, which can in turn allow userspace to take more precise decisions with regard to each PHY's configuration. The numbering is maintained per-netdev, in a phy_device_list. The numbering works similarly to a netdevice's ifindex, with identifiers that are only recycled once INT_MAX has been reached. This prevents races that could occur between PHY listing and SFP transceiver removal/insertion. The identifiers are assigned at phy_attach time, as the numbering depends on the netdevice the phy is attached to. The PHY index can be re-used for PHYs that are persistent. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: drivers/net/ethernet/broadcom/bnxt/bnxt.h c948c097 ("bnxt_en: Don't clear ntuple filters and rss contexts during ethtool ops") f2878cde ("bnxt_en: Add support to call FW to update a VNIC") Link: https://patch.msgid.link/20240822210125.1542769-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== Unmask upper DSCP bits - part 1 tl;dr - This patchset starts to unmask the upper DSCP bits in the IPv4 flow key in preparation for allowing IPv4 FIB rules to match on DSCP. No functional changes are expected. The TOS field in the IPv4 flow key ('flowi4_tos') is used during FIB lookup to match against the TOS selector in FIB rules and routes. It is currently impossible for user space to configure FIB rules that match on the DSCP value as the upper DSCP bits are either masked in the various call sites that initialize the IPv4 flow key or along the path to the FIB core. In preparation for adding a DSCP selector to IPv4 and IPv6 FIB rules, we need to make sure the entire DSCP value is present in the IPv4 flow key. This patchset starts to unmask the upper DSCP bits in the various places that invoke the core FIB lookup functions directly (patches #1-#7) and in the input route path (patches #8-#12). Future patchsets will do the same in the output route path. No functional changes are expected as commit 1fa3314c ("ipv4: Centralize TOS matching") moved the masking of the upper DSCP bits to the core where 'flowi4_tos' is matched against the TOS selector. ==================== Link: https://patch.msgid.link/20240821125251.1571445-1-idosch@nvidia.comSigned-off-by:
-
- 22 Aug, 2024 12 commits
-
-
Ido Schimmel authored
Unmask the upper DSCP bits when performing source validation and routing a packet using the same route from a previously processed packet (hint). In the future, this will allow us to perform the FIB lookup that is performed as part of source validation according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Guillaume Nault <gnault@redhat.com> Acked-by:
Florian Westphal <fw@strlen.de> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20240821125251.1571445-13-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
Unmask the upper DSCP bits when performing source validation for multicast packets during early demux. In the future, this will allow us to perform the FIB lookup which is performed as part of source validation according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
Align the ICMP code to other callers of ip_route_input() and pass the full DS field. In the future this will allow us to perform a route lookup according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
Unmask the upper DSCP bits when looking up an input route via the RTM_GETROUTE netlink message so that in the future the lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
Unmask the upper DSCP bits in input route lookup so that in the future the lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
As explained in commit 35ebf65e ("ipv4: Create and use fib_compute_spec_dst() helper."), the function is used - for example - to determine the source address for an ICMP reply. If we are responding to a multicast or broadcast packet, the source address is set to the source address that we would use if we were to send a packet to the unicast source of the original packet. This address is determined by performing a FIB lookup and using the preferred source address of the resulting route. Unmask the upper DSCP bits of the DS field of the packet that triggered the reply so that in the future the FIB lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
Unmask the upper DSCP bits when calling ipmr_fib_lookup() so that in the future it could perform the FIB lookup according to the full DSCP value. Note that ipmr_fib_lookup() performs a FIB rule lookup (returning the relevant routing table) and that IPv4 multicast FIB rules do not support matching on TOS / DSCP. However, it is still worth unmasking the upper DSCP bits in case support for DSCP matching is ever added. Signed-off-by:
-
Ido Schimmel authored
In a similar fashion to the iptables rpfilter match, unmask the upper DSCP bits of the DS field of the currently tested packet so that in the future the FIB lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
The rpfilter match performs a reverse path filter test on a packet by performing a FIB lookup with the source and destination addresses swapped. Unmask the upper DSCP bits of the DS field of the tested packet so that in the future the FIB lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
The Record Route IP option records the addresses of the routers that routed the packet. In the case of forwarded packets, the kernel performs a route lookup via fib_lookup() and fills in the preferred source address of the matched route. Unmask the upper DSCP bits when performing the lookup so that in the future the lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
The NETLINK_FIB_LOOKUP netlink family can be used to perform a FIB lookup according to user provided parameters and communicate the result back to user space. Unmask the upper DSCP bits of the user-provided DS field before invoking the IPv4 FIB lookup API so that in the future the lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
Ido Schimmel authored
The helper performs a FIB lookup according to the parameters in the 'params' argument, one of which is 'tos'. According to the test in test_tc_neigh_fib.c, it seems that BPF programs are expected to initialize the 'tos' field to the full 8 bit DS field from the IPv4 header. Unmask the upper DSCP bits before invoking the IPv4 FIB lookup APIs so that in the future the lookup could be performed according to the full DSCP value. No functional changes intended since the upper DSCP bits are masked when comparing against the TOS selectors in FIB rules and routes. Signed-off-by:
-
