- 10 Nov, 2022 40 commits
-
-
Ido Schimmel authored
When a devlink port is unregistered, its type is expected to be unset or otherwise a WARNING is generated [1]. This was supposed to be handled by cited commit by clearing the type upon 'NETDEV_PRE_UNINIT'. The assumption was that no other events can be generated for the netdev after this event, but this proved to be wrong. After the event is generated, netdev_wait_allrefs_any() will rebroadcast a 'NETDEV_UNREGISTER' until the netdev's reference count drops to 1. This causes devlink to set the port type back to Ethernet. Fix by only setting and clearing the port type upon 'NETDEV_POST_INIT' and 'NETDEV_PRE_UNINIT', respectively. For all other events, preserve the port type. [1] WARNING: CPU: 0 PID: 11 at net/core/devlink.c:9998 devl_port_unregister+0x2f6/0x390 net/core/devlink.c:9998 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted 6.1.0-rc3-next-20221107-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: netns cleanup_net RIP: 0010:devl_port_unregister+0x2f6/0x390 net/core/devlink.c:9998 [...] Call Trace: <TASK> __nsim_dev_port_del+0x1bb/0x240 drivers/net/netdevsim/dev.c:1433 nsim_dev_port_del_all drivers/net/netdevsim/dev.c:1443 [inline] nsim_dev_reload_destroy+0x171/0x510 drivers/net/netdevsim/dev.c:1660 nsim_dev_reload_down+0x6b/0xd0 drivers/net/netdevsim/dev.c:968 devlink_reload+0x1c2/0x6b0 net/core/devlink.c:4501 devlink_pernet_pre_exit+0x104/0x1c0 net/core/devlink.c:12609 ops_pre_exit_list net/core/net_namespace.c:159 [inline] cleanup_net+0x451/0xb10 net/core/net_namespace.c:594 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> Fixes: 02a68a47 ("net: devlink: track netdev with devlink_port assigned") Reported-by: syzbot+85e47e1a08b3e159b159@syzkaller.appspotmail.com Reported-by: syzbot+c2ca18f0fccdd1f09c66@syzkaller.appspotmail.com Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20221110085150.520800-1-idosch@nvidia.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaJakub Kicinski authored
Long Li says: ==================== Introduce Microsoft Azure Network Adapter (MANA) RDMA driver [netdev prep] The first 11 patches which modify the MANA Ethernet driver to support RDMA driver. * 'mana-shared-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: net: mana: Define data structures for protection domain and memory registration net: mana: Define data structures for allocating doorbell page from GDMA net: mana: Define and process GDMA response code GDMA_STATUS_MORE_ENTRIES net: mana: Define max values for SGL entries net: mana: Move header files to a common location net: mana: Record port number in netdev net: mana: Export Work Queue functions for use by RDMA driver net: mana: Set the DMA device max segment size net: mana: Handle vport sharing between devices net: mana: Record the physical address for doorbell page region net: mana: Add support for auxiliary device ==================== Link: https://lore.kernel.org/all/1667502990-2559-1-git-send-email-longli@linuxonhyperv.com/Signed-off-by:
-
Vincent Mailhol authored
If ethtool_ops::get_drvinfo() callback isn't set, ethtool_get_drvinfo() will fill the ethtool_drvinfo::name and ethtool_drvinfo::bus_info fields. However, if the driver provides the callback function, those two fields are not touched. This means that the driver has to fill these itself. Allow the driver to leave those two fields empty and populate them in such case. This way, the driver can rely on the default values for the name and the bus_info. If the driver provides values, do nothing. Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20221108035754.2143-1-mailhol.vincent@wanadoo.frSigned-off-by:
-
Nathan Huckleberry authored
The ndo_start_xmit field in net_device_ops is expected to be of type netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev). The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition. A new warning in clang will catch this at compile time: drivers/net/ethernet/microsoft/mana/mana_en.c:382:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = mana_start_xmit, ^~~~~~~~~~~~~~~ 1 error generated. The return type of mana_start_xmit should be changed from int to netdev_tx_t. Reported-by:Dan Carpenter <error27@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Link: https://github.com/ClangBuiltLinux/linux/issues/1750Signed-off-by:
Nathan Huckleberry <nhuck@google.com> Reviewed-by:
Dexuan Cui <decui@microsoft.com> [nathan: Rebase on net-next and resolve conflicts Add note about new clang warning] Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20221109002629.1446680-1-nathan@kernel.orgSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Richard Gobert authored
After searching for a protocol handler in dev_gro_receive, checking for failure is redundant. Skip the failure code after finding the corresponding handler. Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Richard Gobert <richardbgobert@gmail.com> Reviewed-by:
-
Ajay Sharma authored
The MANA hardware support protection domain and memory registration for use in RDMA environment. Add those definitions and expose them for use by the RDMA driver. Signed-off-by:
Ajay Sharma <sharmaajay@microsoft.com> Signed-off-by:
Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/1667502990-2559-12-git-send-email-longli@linuxonhyperv.comReviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com>
-
Long Li authored
The RDMA device needs to allocate doorbell pages for each user context. Define the GDMA data structures for use by the RDMA driver. Reviewed-by:
-
Ajay Sharma authored
When doing memory registration, the PF may respond with GDMA_STATUS_MORE_ENTRIES to indicate a follow request is needed. This is not an error and should be processed as expected. Signed-off-by:
-
Long Li authored
The number of maximum SGl entries should be computed from the maximum WQE size for the intended queue type and the corresponding OOB data size. This guarantees the hardware queue can successfully queue requests up to the queue depth exposed to the upper layer. Reviewed-by:
-
Long Li authored
In preparation to add MANA RDMA driver, move all the required header files to a common location for use by both Ethernet and RDMA drivers. Reviewed-by:
-
Long Li authored
The port number is useful for user-mode application to identify this net device based on port index. Set to the correct value in ndev. Reviewed-by:
-
Long Li authored
RDMA device may need to create Ethernet device queues for use by Queue Pair type RAW. This allows a user-mode context accesses Ethernet hardware queues. Export the supporting functions for use by the RDMA driver. Reviewed-by:
-
Ajay Sharma authored
MANA hardware doesn't have any restrictions on the DMA segment size, set it to the max allowed value. Signed-off-by:
-
Long Li authored
For outgoing packets, the PF requires the VF to configure the vport with corresponding protection domain and doorbell ID for the kernel or user context. The vport can't be shared between different contexts. Implement the logic to exclusively take over the vport by either the Ethernet device or RDMA device. Reviewed-by:
-
Long Li authored
For supporting RDMA device with multiple user contexts with their individual doorbell pages, record the start address of doorbell page region for use by the RDMA driver to allocate user context doorbell IDs. Reviewed-by:
-
Long Li authored
In preparation for supporting MANA RDMA driver, add support for auxiliary device in the Ethernet driver. The RDMA device is modeled as an auxiliary device to the Ethernet device. Reviewed-by:
-
Jakub Kicinski authored
Russell King says: ==================== Clean up pcs-xpcs accessors This series cleans up the pcs-xpcs code to use mdiodev accessors for read/write just like xpcs_modify_changed() does. In order to do this, we need to introduce the mdiodev clause 45 accessors. ==================== Link: https://lore.kernel.org/r/Y2pm13+SDg6N/IVx@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Use mdiodev accessors rather than accessing the bus and address in the mdio_device structure and using the mdiobus accessors. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King (Oracle) authored
Signed-off-by:
-
Andy Shevchenko authored
The strlen() may go too far when estimating the length of the given string. In some cases it may go over the boundary and crash the system which is the case according to the commit 13a55372 ("ARM: orion5x: Revert commit 4904dbda."). Rectify this by switching to strnlen() for the expected maximum length of the string. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221108141108.62974-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Tan Tee Min authored
The existing genphy_loopback() is not working for TI DP83867 PHY as it will disable autoneg support while another side is still enabling autoneg. This is causing the link is not established and results in timeout error in genphy_loopback() function. Thus, based on TI PHY datasheet, introduce a TI PHY loopback function by just configuring BMCR_LOOPBACK(Bit-9) in MII_BMCR register (0x0). Tested working on TI DP83867 PHY for all speeds (10/100/1000Mbps). Signed-off-by:
Tan Tee Min <tee.min.tan@linux.intel.com> Reviewed-by:
-
Jakub Kicinski authored
Raju Lakkaraju says: ==================== net: lan743x: PCI11010 / PCI11414 devices Enhancements This patch series continues with the addition of supported features for the Ethernet function of the PCI11010 / PCI11414 devices to the LAN743x driver. ==================== Link: https://lore.kernel.org/r/20221107085650.991470-1-Raju.Lakkaraju@microchip.comSigned-off-by:
-
Raju Lakkaraju authored
Add support to SGMII register dump Signed-off-by:
Raju Lakkaraju <Raju.Lakkaraju@microchip.com> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Raju Lakkaraju authored
Remove the unused argument (i.e. struct ethtool_regs *regs) in lan743x_common_regs( ) function arguments. Signed-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Add 802.1X and MAB offload support This patchset adds 802.1X [1] and MAB [2] offload support in mlxsw. Patches #1-#3 add the required switchdev interfaces. Patches #4-#5 add the required packet traps for 802.1X. Patches #6-#10 are small preparations in mlxsw. Patch #11 adds locked bridge port support in mlxsw. Patches #12-#15 add mlxsw selftests. The patchset was also tested with the generic forwarding selftest ('bridge_locked_port.sh'). [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a21d9a670d81103db7f788de1a4a4a6e4b891a0b [2] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a35ec8e38cdd1766f29924ca391a01de20163931 ==================== Link: https://lore.kernel.org/r/cover.1667902754.git.petrm@nvidia.comSigned-off-by: -
Ido Schimmel authored
Test that locked bridge port configurations that are not supported by mlxsw are rejected. Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Ido Schimmel authored
Test that packets received via a locked bridge port whose {SMAC, VID} does not appear in the bridge's FDB or appears with a different port, trigger the "locked_port" packet trap. Signed-off-by: -
Ido Schimmel authored
Test that packets with a destination MAC of 01:80:C2:00:00:03 trigger the "eapol" packet trap. Signed-off-by:
-
Ido Schimmel authored
Merely checking whether a trap counter incremented or not without logging a test result is useful on its own. Split this functionality to a helper which will be used by subsequent patches. Signed-off-by:
-
Ido Schimmel authored
Add locked bridge port support by reacting to changes in the 'BR_PORT_LOCKED' flag. When set, enable security checks on the local port via the previously added SPFSR register. When security checks are enabled, an incoming packet will trigger an FDB lookup with the packet's source MAC and the FID it was classified to. If an FDB entry was not found or was found to be pointing to a different port, the packet will be dropped. Such packets increment the "discard_ingress_general" ethtool counter. For added visibility, user space can trap such packets to the CPU by enabling the "locked_port" trap. Example: # devlink trap set pci/0000:06:00.0 trap locked_port action trap Unlike other configurations done via bridge port flags (e.g., learning, flooding), security checks are enabled in the device on a per-port basis and not on a per-{port, VLAN} basis. As such, scenarios where user space can configure different locking settings for different VLANs configured on a port need to be vetoed. To that end, veto the following scenarios: 1. Locking is set on a bridge port that is a VLAN upper 2. Locking is set on a bridge port that has VLAN uppers 3. VLAN upper is configured on a locked bridge port Examples: # bridge link set dev swp1.10 locked on Error: mlxsw_spectrum: Locked flag cannot be set on a VLAN upper. # ip link add link swp1 name swp1.10 type vlan id 10 # bridge link set dev swp1 locked on Error: mlxsw_spectrum: Locked flag cannot be set on a bridge port that has VLAN uppers. # bridge link set dev swp1 locked on # ip link add link swp1 name swp1.10 type vlan id 10 Error: mlxsw_spectrum: VLAN uppers are not supported on a locked port. Signed-off-by: -
Ido Schimmel authored
Propagate extack to mlxsw_sp_port_attr_br_pre_flags_set() in order to communicate error messages related to bridge port flag validation. Example: # bridge link set dev swp1 locked on Error: mlxsw_spectrum: Unsupported bridge port flag. More error messages will be added in subsequent patches. Signed-off-by:
-
Ido Schimmel authored
In Spectrum, learning happens in parallel to the security checks. Therefore, regardless of the result of the security checks, a learning notification will be generated by the device and polled later on by the driver. Currently, the driver reacts to learning notifications by programming corresponding FDB entries to the device. When a port is locked (i.e., has security checks enabled), this can no longer happen, as otherwise any host will blindly gain authorization. Instead, notify the learned entry as a locked entry to the bridge driver that will in turn notify it to user space, in case MAB is enabled. User space can then decide to authorize the host by clearing the "locked" flag, which will cause the entry to be programmed to the device. Signed-off-by:
-
Ido Schimmel authored
Subsequent patches will need to report locked FDB entries to the bridge driver. Prepare for that by adding a 'locked' argument to mlxsw_sp_fdb_call_notifiers() according to which the 'locked' bit is set in the FDB notification info. For now, always pass 'false'. Signed-off-by:
-
Ido Schimmel authored
Add an API to enable or disable security checks on a local port. It will be used by subsequent patches when the 'BR_PORT_LOCKED' flag is toggled. Signed-off-by:
-
Ido Schimmel authored
Add the Switch Port FDB Security Register (SPFSR) that allows enabling and disabling security checks on a given local port. In Linux terms, it allows locking / unlocking a port. Signed-off-by:
-
Ido Schimmel authored
Register the previously added packet traps with devlink. This allows user space to tune their policers and in the case of the locked port trap, user space can set its action to "trap" in order to gain visibility into packets that were discarded by the device due to the locked port check failure. Signed-off-by:
-
Ido Schimmel authored
Add packet traps for 802.1X operation. The "eapol" control trap is used to trap EAPOL packets and is required for the correct operation of the control plane. The "locked_port" drop trap can be enabled to gain visibility into packets that were dropped by the device due to the locked bridge port check. Signed-off-by:
-
Ido Schimmel authored
Reflect the 'BR_PORT_MAB' flag to device drivers so that: * Drivers that support MAB could act upon the flag being toggled. * Drivers that do not support MAB will prevent MAB from being enabled. Signed-off-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
-
Hans J. Schultz authored
When the bridge is offloaded to hardware, FDB entries are learned and aged-out by the hardware. Some device drivers synchronize the hardware and software FDBs by generating switchdev events towards the bridge. When a port is locked, the hardware must not learn autonomously, as otherwise any host will blindly gain authorization. Instead, the hardware should generate events regarding hosts that are trying to gain authorization and their MAC addresses should be notified by the device driver as locked FDB entries towards the bridge driver. Allow device drivers to notify the bridge driver about such entries by extending the 'switchdev_notifier_fdb_info' structure with the 'locked' bit. The bit can only be set by device drivers and not by the bridge driver. Prevent a locked entry from being installed if MAB is not enabled on the bridge port. If an entry already exists in the bridge driver, reject the locked entry if the current entry does not have the "locked" flag set or if it points to a different port. The same semantics are implemented in the software data path. Signed-off-by:
Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by:
-
Ido Schimmel authored
Currently, FDB entries that are notified to the bridge via 'SWITCHDEV_FDB_ADD_TO_BRIDGE' are always marked as offloaded. With MAB enabled, this will no longer be universally true. Device drivers will report locked FDB entries to the bridge to let it know that the corresponding hosts required authorization, but it does not mean that these entries are necessarily programmed in the underlying hardware. Solve this by determining the offload indication based of the 'offloaded' bit in the FDB notification. Signed-off-by:
-
