- Nov 04, 2022
-
-
Nathan Chancellor authored
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/ti/netcp_core.c:1944: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 = netcp_ndo_start_xmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221102160933.1601260-1-nathan@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Christophe JAILLET authored
strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file (<linux/kstrtox.h>). Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/d4432a67b6f769cac0a9ec910ac725298b64e102.1667336095.git.christophe.jaillet@wanadoo.fr Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Jiri Pirko says: ==================== net: fix netdev to devlink_port linkage and expose to user Currently, the info about linkage from netdev to the related devlink_port instance is done using ndo_get_devlink_port(). This is not sufficient, as it is up to the driver to implement it and some of them don't do that. Also it leads to a lot of unnecessary boilerplate code in all the drivers. Instead of that, introduce a possibility for driver to expose this relationship by new SET_NETDEV_DEVLINK_PORT macro which stores it into dev->devlink_port. It is ensured by the driver init/fini flows that the devlink_port pointer does not change during the netdev lifetime. Devlink port is always registered before netdev register and unregistered after netdev unregister. Benefit from this linkage setup and remove explicit calls from driver to devlink_port_type_eth_set() and clear(). Many of the driver didn't use it correctly anyway. Let the devlink.c to track associated netdev events and adjust type and type pointer accordingly. Also use this events to to keep track on ifname change and remove RTNL lock taking from devlink_nl_port_fill(). Finally, remove the ndo_get_devlink_port() ndo which is no longer used and expose devlink_port handle as a new netdev netlink attribute to the user. That way, during the ifname->devlink_port lookup, userspace app does not have to dump whole devlink port list and instead it can just do a simple RTM_GETLINK query. ==================== Link: https://lore.kernel.org/r/20221102160211.662752-1-jiri@resnulli.us Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Expose devlink port handle related to netdev over rtnetlink. Introduce a new nested IFLA attribute to carry the info. Call into devlink code to fill-up the nest with existing devlink attributes that are used over devlink netlink. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Remove ndo_get_devlink_port which is no longer used alongside with the implementations in drivers. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Use newly introduced devlink_port pointer instead of getting it calling to ndo_get_devlink_port op. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
By the time port unregister is called. There should be no type set. Make sure that the driver cleared it before and warn in case it didn't. This enforces symmetricity with type set and port register. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
To avoid a need to take RTNL mutex in port_fill() function, benefit from the introduce infrastructure that tracks netdevice notifier events. Store the ifindex and ifname upon register and change name events. Remove the rtnl_held bool propagated down to port_fill() function as it is no longer needed. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
It is ensured by the netdevice notifier event processing, that only netdev pointers from the same net namespaces are filled. Remove the net namespace check from devlink_nl_port_fill() as it is no longer needed. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Since devlink_port_type_eth_set() should no longer be called by any driver with netdev pointer as it should rather use SET_NETDEV_DEVLINK_PORT, remove the netdev arg. Add a warn to type_clear() Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Benefit from the previously implemented tracking of netdev events in devlink code and instead of calling devlink_port_type_eth_set() and devlink_port_type_clear() to set devlink port type and link to related netdev, use SET_NETDEV_DEVLINK_PORT() macro to assign devlink_port pointer to netdevice which is about to be registered. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Currently, ethernet drivers are using devlink_port_type_eth_set() and devlink_port_type_clear() to set devlink port type and link to related netdev. Instead of calling them directly, let the driver use SET_NETDEV_DEVLINK_PORT macro to assign devlink_port pointer and let devlink to track it. Note the devlink port pointer is static during the time netdevice is registered. In devlink code, use per-namespace netdev notifier to track the netdevices with devlink_port assigned and change the internal devlink_port type and related type pointer accordingly. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Follow-up patch is going to introduce a netdevice notifier event processing which is called with RTNL mutex held. Processing of this will eventually lead to call to port_notity() and port_fill() which currently takes RTNL mutex internally. So as a temporary solution, propagate a bool indicating if the mutex is already held. This will go away in one of the follow-up patches. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
As __devlink_port_type_set() is going to be called directly from netdevice notifier event handle in one of the follow-up patches, move the port_type_netdev_checks() call there. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
As __devlink_port_type_set() is going to be called directly from netdevice notifier event handle in one of the follow-up patches, move the port_type_warn_schedule() call there. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Instead of storing type_dev as a void pointer, convert it to union and use it to store either struct net_device or struct ib_device pointer. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Ido Schimmel says: ==================== bridge: Add MAC Authentication Bypass (MAB) support Patch #1 adds MAB support in the bridge driver. See the commit message for motivation, design choices and implementation details. Patch #2 adds corresponding test cases. Follow-up patchsets will add offload support in mlxsw and mv88e6xxx. ==================== Link: https://lore.kernel.org/r/20221101193922.2125323-1-idosch@nvidia.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Hans J. Schultz authored
Add four test cases to verify MAB functionality: * Verify that a locked FDB entry can be generated by the bridge, preventing a host from communicating via the bridge. Test that user space can clear the "locked" flag by replacing the entry, thereby authenticating the host and allowing it to communicate via the bridge. * Test that an entry cannot roam to a locked port, but that it can roam to an unlocked port. * Test that MAB can only be enabled on a port that is both locked and has learning enabled. * Test that locked FDB entries are flushed from a port when MAB is disabled. Signed-off-by:
Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Hans J. Schultz authored
Hosts that support 802.1X authentication are able to authenticate themselves by exchanging EAPOL frames with an authenticator (Ethernet bridge, in this case) and an authentication server. Access to the network is only granted by the authenticator to successfully authenticated hosts. The above is implemented in the bridge using the "locked" bridge port option. When enabled, link-local frames (e.g., EAPOL) can be locally received by the bridge, but all other frames are dropped unless the host is authenticated. That is, unless the user space control plane installed an FDB entry according to which the source address of the frame is located behind the locked ingress port. The entry can be dynamic, in which case learning needs to be enabled so that the entry will be refreshed by incoming traffic. There are deployments in which not all the devices connected to the authenticator (the bridge) support 802.1X. Such devices can include printers and cameras. One option to support such deployments is to unlock the bridge ports connecting these devices, but a slightly more secure option is to use MAB. When MAB is enabled, the MAC address of the connected device is used as the user name and password for the authentication. For MAB to work, the user space control plane needs to be notified about MAC addresses that are trying to gain access so that they will be compared against an allow list. This can be implemented via the regular learning process with the sole difference that learned FDB entries are installed with a new "locked" flag indicating that the entry cannot be used to authenticate the device. The flag cannot be set by user space, but user space can clear the flag by replacing the entry, thereby authenticating the device. Locked FDB entries implement the following semantics with regards to roaming, aging and forwarding: 1. Roaming: Locked FDB entries can roam to unlocked (authorized) ports, in which case the "locked" flag is cleared. FDB entries cannot roam to locked ports regardless of MAB being enabled or not. Therefore, locked FDB entries are only created if an FDB entry with the given {MAC, VID} does not already exist. This behavior prevents unauthenticated devices from disrupting traffic destined to already authenticated devices. 2. Aging: Locked FDB entries age and refresh by incoming traffic like regular entries. 3. Forwarding: Locked FDB entries forward traffic like regular entries. If user space detects an unauthorized MAC behind a locked port and wishes to prevent traffic with this MAC DA from reaching the host, it can do so using tc or a different mechanism. Enable the above behavior using a new bridge port option called "mab". It can only be enabled on a bridge port that is both locked and has learning enabled. Locked FDB entries are flushed from the port once MAB is disabled. A new option is added because there are pure 802.1X deployments that are not interested in notifications about locked FDB entries. Signed-off-by:
Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth and netfilter. Current release - regressions: - net: several zerocopy flags fixes - netfilter: fix possible memory leak in nf_nat_init() - openvswitch: add missing .resv_start_op Previous releases - regressions: - neigh: fix null-ptr-deref in neigh_table_clear() - sched: fix use after free in red_enqueue() - dsa: fall back to default tagger if we can't load the one from DT - bluetooth: fix use-after-free in l2cap_conn_del() Previous releases - always broken: - netfilter: netlink notifier might race to release objects - nfc: fix potential memory leak of skb - bluetooth: fix use-after-free caused by l2cap_reassemble_sdu - bluetooth: use skb_put to set length - eth: tun: fix bugs for oversize packet when napi frags enabled - eth: lan966x: fixes for when MTU is changed - eth: dwmac-loongson: fix invalid mdio_node" * tag 'net-6.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (53 commits) vsock: fix possible infinite sleep in vsock_connectible_wait_data() vsock: remove the unused 'wait' in vsock_connectible_recvmsg() ipv6: fix WARNING in ip6_route_net_exit_late() bridge: Fix flushing of dynamic FDB entries net, neigh: Fix null-ptr-deref in neigh_table_clear() net/smc: Fix possible leaked pernet namespace in smc_init() stmmac: dwmac-loongson: fix invalid mdio_node ibmvnic: Free rwi on reset success net: mdio: fix undefined behavior in bit shift for __mdiobus_register Bluetooth: L2CAP: Fix attempting to access uninitialized memory Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM Bluetooth: hci_conn: Fix not restoring ISO buffer count on disconnect Bluetooth: L2CAP: Fix memory leak in vhci_write Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() Bluetooth: virtio_bt: Use skb_put to set length Bluetooth: hci_conn: Fix CIS connection dst_type handling Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu netfilter: ipset: enforce documented limit to prevent allocating huge memory isdn: mISDN: netjet: fix wrong check of device registration ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Fix an endian thinko in the asm-generic compat_arg_u64() which led to syscall arguments being swapped for some compat syscalls. - Fix syscall wrapper handling of syscalls with 64-bit arguments on 32-bit kernels, which led to syscall arguments being misplaced. - A build fix for amdgpu on Book3E with AltiVec disabled. Thanks to Andreas Schwab, Christian Zigotzky, and Arnd Bergmann. * tag 'powerpc-6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/32: Select ARCH_SPLIT_ARG64 powerpc/32: fix syscall wrappers with 64-bit arguments asm-generic: compat: fix compat_arg_u64() and compat_arg_u64_dual() powerpc/64e: Fix amdgpu build on Book3E w/o AltiVec
-
- Nov 03, 2022
-
-
Paolo Abeni authored
Daniel Machon says: ==================== Add new PCP and APPTRUST attributes to dcbnl This patch series adds new extension attributes to dcbnl, to support PCP prioritization (and thereby hw offloadable pcp-based queue classification) and per-selector trust and trust order. Additionally, the microchip sparx5 driver has been dcb-enabled to make use of the new attributes to offload PCP, DSCP and Default prio to the switch, and implement trust order of selectors. For pre-RFC discussion see: https://lore.kernel.org/netdev/Yv9VO1DYAxNduw6A@DEN-LT-70577/ For RFC series see: https://lore.kernel.org/netdev/20220915095757.2861822-1-daniel.machon@microchip.com/ In summary: there currently exist no convenient way to offload per-port PCP-based queue classification to hardware. The DCB subsystem offers different ways to prioritize through its APP table, but lacks an option for PCP. Similarly, there is no way to indicate the notion of trust for APP table selectors. This patch series addresses both topics. PCP based queue classification: - 8021Q standardizes the Priority Code Point table (see 6.9.3 of IEEE Std 802.1Q-2018). This patch series makes it possible, to offload the PCP classification to said table. The new PCP selector is not a standard part of the APP managed object, therefore it is encapsulated in a new non-std extension attribute. Selector trust: - ASIC's often has the notion of trust DSCP and trust PCP. The new attribute makes it possible to specify a trust order of app selectors, which drivers can then react on. DCB-enable sparx5 driver: - Now supports offloading of DSCP, PCP and default priority. Only one mapping of protocol:priority is allowed. Consecutive mappings of the same protocol to some new priority, will overwrite the previous. This is to keep a consistent view of the app table and the hardware. - Now supports dscp and pcp trust, by use of the introduced dcbnl_set/getapptrust ops. Sparx5 supports trust orders: [], [dscp], [pcp] and [dscp, pcp]. For now, only DSCP and PCP selectors are supported by the driver, everything else is bounced. Patch #1 introduces a new PCP selector to the APP object, which makes it possible to encode PCP and DEI in the app triplet and offload it to the PCP table of the ASIC. Patch #2 Introduces the new extension attributes DCB_ATTR_DCB_APP_TRUST_TABLE and DCB_ATTR_DCB_APP_TRUST. Trusted selectors are passed in the nested DCB_ATTR_DCB_APP_TRUST_TABLE attribute, and assembled into an array of selectors: u8 selectors[256]; where lower indexes has higher precedence. In the array, selectors are stored consecutively, starting from index zero. With a maximum number of 256 unique selectors, the list has the same maximum size. Patch #3 Sets up the dcbnl ops hook, and adds support for offloading pcp app entries, to the PCP table of the switch. Patch #4 Makes use of the dcbnl_set/getapptrust ops, to set a per-port trust order. Patch #5 Adds support for offloading dscp app entries to the DSCP table of the switch. Patch #6 Adds support for offloading default prio app entries to the switch. ==================== Link: https://lore.kernel.org/r/20221101094834.2726202-1-daniel.machon@microchip.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Add support for offloading default prio {ETHERTYPE, 0, prio}. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Add support for offloading dscp app entries. Dscp values are global for all ports on the sparx5 switch. Therefore, we replicate each dscp app entry per-port. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Make use of set/getapptrust() to implement per-selector trust and trust order. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Add new registers and functions to support offload of pcp app entries. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Add new apptrust extension attributes to the 8021Qaz APP managed object. Two new attributes, DCB_ATTR_DCB_APP_TRUST_TABLE and DCB_ATTR_DCB_APP_TRUST, has been added. Trusted selectors are passed in the nested attribute DCB_ATTR_DCB_APP_TRUST, in order of precedence. The new attributes are meant to allow drivers, whose hw supports the notion of trust, to be able to set whether a particular app selector is trusted - and in which order. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Daniel Machon authored
Add new PCP selector for the 8021Qaz APP managed object. As the PCP selector is not part of the 8021Qaz standard, a new non-std extension attribute DCB_ATTR_DCB_APP has been introduced. Also two helper functions to translate between selector and app attribute type has been added. The new selector has been given a value of 255, to minimize the risk of future overlap of std- and non-std attributes. The new DCB_ATTR_DCB_APP is sent alongside the ieee std attribute in the app table. This means that the dcb_app struct can now both contain std- and non-std app attributes. Currently there is no overlap between the selector values of the two attributes. The purpose of adding the PCP selector, is to be able to offload PCP-based queue classification to the 8021Q Priority Code Point table, see 6.9.3 of IEEE Std 802.1Q-2018. PCP and DEI is encoded in the protocol field as 8*dei+pcp, so that a mapping of PCP 2 and DEI 1 to priority 3 is encoded as {255, 10, 3}. Signed-off-by:
Daniel Machon <daniel.machon@microchip.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Saurabh Sengar authored
In large VMs with multiple NUMA nodes, network performance is usually best if network interrupts are all assigned to the same virtual NUMA node. This patch assigns online CPU according to a numa aware policy, local cpus are returned first, followed by non-local ones, then it wraps around. Signed-off-by:
Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Link: https://lore.kernel.org/r/1667282761-11547-1-git-send-email-ssengar@linux.microsoft.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Dexuan Cui says: ==================== vsock: remove an unused variable and fix infinite sleep Patch 1 removes the unused 'wait' variable. Patch 2 fixes an infinite sleep issue reported by a hv_sock user. ==================== Link: https://lore.kernel.org/r/20221101021706.26152-1-decui@microsoft.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Dexuan Cui authored
Currently vsock_connectible_has_data() may miss a wakeup operation between vsock_connectible_has_data() == 0 and the prepare_to_wait(). Fix the race by adding the process to the wait queue before checking vsock_connectible_has_data(). Fixes: b3f7fd54 ("af_vsock: separate wait data loop") Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reported-by:
Frédéric Dalleau <frederic.dalleau@docker.com> Tested-by:
Frédéric Dalleau <frederic.dalleau@docker.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Dexuan Cui authored
Remove the unused variable introduced by 19c1b90e. Fixes: 19c1b90e ("af_vsock: separate receive data loop") Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Shenwei Wang authored
This patch adds the initial XDP support to Freescale driver. It supports XDP_PASS, XDP_DROP and XDP_REDIRECT actions. Upcoming patches will add support for XDP_TX and Zero Copy features. As the patch is rather large, the part of codes to collect the statistics is separated and will prepare a dedicated patch for that part. I just tested with the application of xdpsock. -- Native here means running command of "xdpsock -i eth0" -- SKB-Mode means running command of "xdpsock -S -i eth0" The following are the testing result relating to XDP mode: root@imx8qxpc0mek:~/bpf# ./xdpsock -i eth0 sock0@eth0:0 rxdrop xdp-drv pps pkts 1.00 rx 371347 2717794 tx 0 0 root@imx8qxpc0mek:~/bpf# ./xdpsock -S -i eth0 sock0@eth0:0 rxdrop xdp-skb pps pkts 1.00 rx 202229 404528 tx 0 0 root@imx8qxpc0mek:~/bpf# ./xdp2 eth0 proto 0: 496708 pkt/s proto 0: 505469 pkt/s proto 0: 505283 pkt/s proto 0: 505443 pkt/s proto 0: 505465 pkt/s root@imx8qxpc0mek:~/bpf# ./xdp2 -S eth0 proto 0: 0 pkt/s proto 17: 118778 pkt/s proto 17: 118989 pkt/s proto 0: 1 pkt/s proto 17: 118987 pkt/s proto 0: 0 pkt/s proto 17: 118943 pkt/s proto 17: 118976 pkt/s proto 0: 1 pkt/s proto 17: 119006 pkt/s proto 0: 0 pkt/s proto 17: 119071 pkt/s proto 17: 119092 pkt/s Signed-off-by:
Shenwei Wang <shenwei.wang@nxp.com> Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20221031185350.2045675-1-shenwei.wang@nxp.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Ilya Maximets authored
The 10Mbps link speed was set in 2004 when the ethtool interface was initially added to the tun driver. It might have been a good assumption 18 years ago, but CPUs and network stack came a long way since then. Other virtual ports typically report much higher speeds. For example, veth reports 10Gbps since its introduction in 2007. Some userspace applications rely on the current link speed in certain situations. For example, Open vSwitch is using link speed as an upper bound for QoS configuration if user didn't specify the maximum rate. Advertised 10Mbps doesn't match reality in a modern world, so users have to always manually override the value with something more sensible to avoid configuration issues, e.g. limiting the traffic too much. This also creates additional confusion among users. Bump the advertised speed to at least match the veth. Alternative might be to explicitly report UNKNOWN and let the user decide on a right value for them. And it is indeed "the right way" of fixing the problem. However, that may cause issues with bonding or with some userspace applications that may rely on speed value to be reported (even though they should not). Just changing the speed value should be a safer option. Users can still override the speed with ethtool, if necessary. RFC discussion is linked below. Link: https://lore.kernel.org/lkml/20221021114921.3705550-1-i.maximets@ovn.org/ Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051958.html Signed-off-by:
Ilya Maximets <i.maximets@ovn.org> Reviewed-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20221031173953.614577-1-i.maximets@ovn.org Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Zhengchao Shao authored
During the initialization of ip6_route_net_init_late(), if file ipv6_route or rt6_stats fails to be created, the initialization is successful by default. Therefore, the ipv6_route or rt6_stats file doesn't be found during the remove in ip6_route_net_exit_late(). It will cause WRNING. The following is the stack information: name 'rt6_stats' WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked in: Workqueue: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 PKRU: 55555554 Call Trace: <TASK> ops_exit_list+0xb0/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK> Fixes: cdb18761 ("[NETNS][IPV6] route6 - create route6 proc files for the namespace") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20221102020610.351330-1-shaozhengchao@huawei.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
The following commands should result in all the dynamic FDB entries being flushed, but instead all the non-local (non-permanent) entries are flushed: # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic # ip link set dev br0 type bridge fdb_flush # bridge fdb show brport dummy1 00:00:00:00:00:01 master br0 permanent 33:33:00:00:00:01 self permanent 01:00:5e:00:00:01 self permanent This is because br_fdb_flush() works with FDB flags and not the corresponding enumerator values. Fix by passing the FDB flag instead. After the fix: # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic # ip link set dev br0 type bridge fdb_flush # bridge fdb show brport dummy1 00:aa:bb:cc:dd:ee master br0 static 00:00:00:00:00:01 master br0 permanent 33:33:00:00:00:01 self permanent 01:00:5e:00:00:01 self permanent Fixes: 1f78ee14 ("net: bridge: fdb: add support for fine-grained flushing") Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Link: https://lore.kernel.org/r/20221101185753.2120691-1-idosch@nvidia.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Ido Schimmel says: ==================== rocker: Two small changes Patch #1 avoids allocating and scheduling a work item when it is not doing any work. Patch #2 aligns rocker with other switchdev drivers to explicitly mark FDB entries as offloaded. Needed for upcoming MAB offload [1]. [1] https://lore.kernel.org/netdev/20221025100024.1287157-1-idosch@nvidia.com/ ==================== Link: https://lore.kernel.org/r/20221101123936.1900453-1-idosch@nvidia.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
Currently, FDB entries that are notified to the bridge driver via 'SWITCHDEV_FDB_ADD_TO_BRIDGE' are always marked as offloaded by the bridge. 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. We would like to solve it by having the bridge driver determine the offload indication based of the 'offloaded' bit in the FDB notification [1]. Prepare for that change by having rocker explicitly mark learned FDB entries as offloaded. This is consistent with all the other switchdev drivers. [1] https://lore.kernel.org/netdev/20221025100024.1287157-4-idosch@nvidia.com/ Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
The work item function ofdpa_port_fdb_learn_work() does not do anything when 'OFDPA_OP_FLAG_LEARNED' is not set in the work item's flags. Therefore, do not allocate and do not schedule the work item when the flag is not set. Suggested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-