- 04 Oct, 2019 32 commits
-
-
Jiri Pirko authored
Currently, some dumpit function may end-up with error which is not -EMSGSIZE and this error is silently ignored. Use does not have clue that something wrong happened. Instead of silent ignore, propagate the error to user. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Amazingly, of all features, this does not require a switch reset. Tested with: tc qdisc add dev swp2 clsact tc filter add dev swp2 ingress matchall skip_sw \ action mirred egress mirror dev swp3 tc filter show dev swp2 ingress tc filter del dev swp2 ingress pref 49152 Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
This function is only used via function pointer. "inline" doesn't hurt given that taking address of an inline function forces out-of-line version but it doesn't help either. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
Some ints are "enum sock_flags" in fact. Signed-off-by:
-
Alexey Dobriyan authored
Add casts to fix these warnings: ./usr/include/linux/netfilter_arp/arp_tables.h:200:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/netfilter_bridge/ebtables.h:197:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/netfilter_ipv4/ip_tables.h:223:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/netfilter_ipv6/ip6_tables.h:263:19: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/tipc_config.h:310:28: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/tipc_config.h:410:24: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] ./usr/include/linux/virtio_ring.h:170:16: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] Those are theoretical probably but kernel doesn't control compiler flags in userspace. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: broadcom: RGMII delays fixes This patch series fixes the BCM54210E RGMII delay configuration which could only have worked in a PHY_INTERFACE_MODE_RGMII configuration. There is a forward declaration added such that the first patch can be picked up for -stable and apply fine all the way back to when the bug was introduced. The second patch eliminates duplicated code that used a different kind of logic and did not use existing constants defined. ==================== Signed-off-by: -
Florian Fainelli authored
bcm54612e_config_init() duplicates what bcm54xx_config_clock_delay() does with respect to configuring RGMII TX/RX delays appropriately. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Commit 0fc9ae10 ("net: phy: broadcom: add support for BCM54210E") added support for BCM54210E but also unconditionally cleared the RXC to RXD skew and the TXD to TXC skew, thus only making PHY_INTERFACE_MODE_RGMII a possible configuration. Use bcm54xx_config_clock_delay() which correctly sets the registers depending on the 4 possible PHY interface values that exist for RGMII. Fixes: 0fc9ae10 ("net: phy: broadcom: add support for BCM54210E") Reported-by:
Manasa Mudireddy <manasa.mudireddy@broadcom.com> Reported-by:
Ray Jui <ray.jui@broadcom.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== net/tls: separate the TLS TOE code out We have 3 modes of operation of TLS - software, crypto offload (Mellanox, Netronome) and TCP Offload Engine-based (Chelsio). The last one takes over the socket, like any TOE would, and is not really compatible with how we want to do things in the networking stack. Confusingly the name of the crypto-only offload mode is TLS_HW, while TOE-offload related functions use tls_hw_ as their prefix. Engineers looking to implement offload are also be faced with TOE artefacts like struct tls_device (while, again, CONFIG_TLS_DEVICE actually gates the non-TOE offload). To improve the clarity of the offload code move the TOE code into new files, and rename the functions and structures appropriately. Because TOE-offload takes over the socket, and makes no use of the TLS infrastructure in the kernel, the rest of the code (anything beyond the ULP setup handlers) do not have to worry about the mode == TLS_HW_RECORD case. The increase in code size is due to duplication of the full license boilerplate. Unfortunately original author (Dave Watson) seems unreachable :( ==================== Signed-off-by: -
Jakub Kicinski authored
TLS "record layer offload" requires TOE, and bypasses most of the normal networking stack. It is also significantly less maintained. Allow users to compile it out to avoid issues. Signed-off-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
The tls_hw_* functions are quite confusingly named, since they are related to the TOE-offload, not TLS_HW offload which doesn't require TOE. Rename them. Signed-off-by:
-
Jakub Kicinski authored
Move tls_hw_* functions to a new, separate source file to avoid confusion with normal, non-TOE offload. Signed-off-by:
-
Jakub Kicinski authored
Move tls_build_proto() so that TOE offload doesn't have to call it mid way through its bypass enable path. Signed-off-by:
-
Jakub Kicinski authored
Rename struct tls_device to struct tls_toe_device to avoid confusion with normal, non-TOE offload. No functional changes. Signed-off-by:
-
Jakub Kicinski authored
Move tls_device structure and register/unregister functions to a new header to avoid confusion with normal, non-TOE offload. Signed-off-by:
-
David Howells authored
There was supposed to be a trace indicating that a new peer had been created. Add it. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== devlink: allow devlink instances to change network namespace Devlink from the beginning counts with network namespaces, but the instances has been fixed to init_net. Implement change of network namespace as part of "devlink reload" procedure like this: $ ip netns add testns1 $ devlink/devlink dev reload netdevsim/netdevsim10 netns testns1 This command reloads device "netdevsim10" into network namespace "testns1". Note that "devlink reload" reinstantiates driver objects, effectively it reloads the driver instance, including possible hw reset etc. Newly created netdevices respect the network namespace of the parent devlink instance and according to that, they are created in target network namespace. Driver is able to refuse to be reloaded into different namespace. That is the case of mlx4 right now. FIB entries and rules are replayed during FIB notifier registration which is triggered during reload (driver instance init). FIB notifier is also registered to the target network namespace, that allows user to use netdevsim devlink resources to setup per-namespace limits of FIB entries and FIB rules. In fact, with multiple netdevsim instances in each network namespace, user might setup different limits. This maintains and extends current netdevsim resources behaviour. Patch 1 prepares netdevsim code for the follow-up changes in the patchset. It does not change the behaviour, only moves pet-init_netns accounting to netdevsim instance, which is also in init_netns. Patches 2-5 prepare the FIB notifier making it per-netns and to behave correctly upon error conditions. Patch 6 just exports a devlink_net helper so it can be used in drivers. Patches 7-9 do preparations in mlxsw driver. Patches 10-13 do preparations in netdevsim driver, namely patch 12 implements proper devlink reload where the driver instance objects are actually re-created as they should be. Patch 14 actually implements the possibility to reload into a different network namespace. Patch 15 adds needed selftests for devlink reload into namespace for netdevsim driver. ==================== Signed-off-by: -
Jiri Pirko authored
Add couple of tests for devlink reload testing and also resource limitations testing, along with devlink reload. Signed-off-by:
-
Jiri Pirko authored
All devlink instances are created in init_net and stay there for a lifetime. Allow user to be able to move devlink instances into namespaces during devlink reload operation. That ensures proper re-instantiation of driver objects, including netdevices. Signed-off-by:
-
Jiri Pirko authored
Follow-up patch is going to allow to reload devlink instance into different network namespace, so use devlink_net() helper instead of init_net. Signed-off-by:
-
Jiri Pirko authored
Register newly created port netdevice into net namespace that the parent device belongs to. Signed-off-by:
-
Jiri Pirko authored
During devlink reload, all driver objects should be reinstantiated with the exception of devlink instance and devlink resources and params. Move existing devlink_resource_size_get() calls into fib_create() just before fib notifier is registered. Also, make sure that extack is propagated down to fib_notifier_register() call. Signed-off-by:
-
Jiri Pirko authored
Currently the probe/remove function does this separately. Put the addition an deletion of ports into nsim_dev_create() and nsim_dev_destroy(). Signed-off-by:
-
Jiri Pirko authored
During the devlink reaload the extack is present, so propagate it all the way down to register_fib_notifier() call in spectrum_router.c. Signed-off-by:
-
Jiri Pirko authored
When creating netdevices for ports, put them under network namespace that the core/parent devlink belongs to. Signed-off-by:
-
Jiri Pirko authored
Follow-up patch is going to allow to reload devlink instance into different network namespace, so use devlink_net() helper instead of init_net. Signed-off-by:
-
Jiri Pirko authored
Allow drivers to get net struct for devlink instance. Signed-off-by:
-
Jiri Pirko authored
Since errors are propagated all the way up to the caller, propagate possible extack of the caller all the way down to the notifier block callback. Signed-off-by:
-
Jiri Pirko authored
Currently if info->extack is NULL, mlxsw assumes that the event came down from dump. Originally, the dump did not propagate the return value back to the original caller (fib_notifier_register()). However, that is now happening. So benefit from this and push the error up if it happened. Remove rule cases in work handlers that are now dead code. Signed-off-by:
-
Jiri Pirko authored
Unlike events for registered notifier, during the registration, the errors that happened for the block being registered are not propagated up to the caller. Make sure the error is propagated for FIB rules and entries. Signed-off-by:
-
Jiri Pirko authored
Currently all users of FIB notifier only cares about events in init_net. Later in this patchset, users get interested in other namespaces too. However, for every registered block user is interested only about one namespace. Make the FIB notifier registration per-netns and avoid unnecessary calls of notifier block for other namespaces. Signed-off-by:
-
Jiri Pirko authored
Currently, the accounting is done per-namespace. However, devlink instance is always in init_net namespace for now, so only the accounting related to init_net is used. Limitations set using devlink resources are only considered for init_net. nsim_devlink_net() always returns init_net always. Make the accounting per-device. This brings no functional change. Per-device accounting has the same values as per-net. For a single netdevsim instance, the behaviour is exactly the same as before. When multiple netdevsim instances are created, each can have different limits. This is in prepare to implement proper devlink netns support. After that, the devlink instance which would exist in particular netns would account and limit that netns. Signed-off-by:
-
- 03 Oct, 2019 8 commits
-
-
Eric Dumazet authored
If netdev_name_node_head_alloc() fails to allocate memory, we absolutely want register_netdevice() to return -ENOMEM instead of zero :/ One of the syzbot report looked like : general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8760 Comm: syz-executor839 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ovs_vport_add+0x185/0x500 net/openvswitch/vport.c:205 Code: 89 c6 e8 3e b6 3a fa 49 81 fc 00 f0 ff ff 0f 87 6d 02 00 00 e8 8c b4 3a fa 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 d3 02 00 00 49 8d 7c 24 08 49 8b 34 24 48 b8 00 RSP: 0018:ffff88808fe5f4e0 EFLAGS: 00010247 RAX: dffffc0000000000 RBX: ffffffff89be8820 RCX: ffffffff87385162 RDX: 0000000000000000 RSI: ffffffff87385174 RDI: 0000000000000007 RBP: ffff88808fe5f510 R08: ffff8880933c6600 R09: fffffbfff14ee13c R10: fffffbfff14ee13b R11: ffffffff8a7709df R12: 0000000000000004 R13: ffffffff89be8850 R14: ffff88808fe5f5e0 R15: 0000000000000002 FS: 0000000001d71880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000280 CR3: 0000000096e4c000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: new_vport+0x1b/0x1d0 net/openvswitch/datapath.c:194 ovs_dp_cmd_new+0x5e5/0xe30 net/openvswitch/datapath.c:1644 genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629 genl_rcv_msg+0xca/0x170 net/netlink/genetlink.c:654 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 genl_rcv+0x29/0x40 net/netlink/genetlink.c:665 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x803/0x920 net/socket.c:2311 __sys_sendmsg+0x105/0x1d0 net/socket.c:2356 __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg net/socket.c:2363 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363 Fixes: ff927412 ("net: introduce name_node struct to be used in hashlist") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Jiri Pirko <jiri@mellanox.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Tested-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
-
David S. Miller authored
Oleksij Rempel says: ==================== phy: at803x: add ar9331 support changes v3: - use PHY_ID_MATCH_EXACT only for ATH9331 PHY changes v2: - use PHY_ID_MATCH_EXACT instead of leaky masking - remove probe and struct at803x_priv ==================== Signed-off-by: -
Oleksij Rempel authored
struct at803x_priv is never used in this driver. So remove it and the probe function allocating it. Suggested-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
-
Oleksij Rempel authored
Mostly this hardware can work with generic PHY driver, but this change is needed to provided interrupt handling support. Tested with dsa ar9331-switch driver. Signed-off-by:
-
Petr Machata authored
Currently mlxsw distributes sent traffic among all the available send queues. That includes control traffic as well as EMADs, which are used for configuration of the device. However because all the queues have the same traffic class of 3, they all end up being directed to the same traffic class buffer. If the control traffic in the buffer cannot be serviced quickly enough, the EMAD traffic might be shut out, which causes transient failures, typically in FDB maintenance, counter upkeep and other periodic work. To address this issue, dedicate SDQ 0 to EMAD traffic, with TC 0. Distribute the control traffic among the remaining queues, which are left with their current TC 3. Suggested-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Petr Machata <petrm@mellanox.com> Acked-by:
-
Ka-Cheong Poon authored
Currently, RDS calls ib_dma_alloc_coherent() to allocate a large piece of contiguous DMA coherent memory to store struct rds_header for sending/receiving packets. The memory allocated is then partitioned into struct rds_header. This is not necessary and can be costly at times when memory is fragmented. Instead, RDS should use the DMA memory pool interface to handle this. The DMA addresses of the pre- allocated headers are stored in an array. At send/receive ring initialization and refill time, this arrary is de-referenced to get the DMA addresses. This array is not accessed at send/receive packet processing. Suggested-by:
Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by:
Ka-Cheong Poon <ka-cheong.poon@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
David S. Miller authored
Thierry Reding says: ==================== net: stmmac: Enhanced addressing mode for DWMAC 4.10 The DWMAC 4.10 supports the same enhanced addressing mode as later generations. Parse this capability from the hardware feature registers and set the EAME (Enhanced Addressing Mode Enable) bit when necessary. ==================== Signed-off-by: -
Thierry Reding authored
The address width of the controller can be read from hardware feature registers much like on XGMAC. Add support for parsing the ADDR64 field so that the DMA mask can be set accordingly. This avoids getting swiotlb involved for DMA on Tegra186 and later. Also make sure that the upper 32 bits of the DMA address are written to the DMA descriptors when enhanced addressing mode is used. Similarily, for each channel, the upper 32 bits of the DMA descriptor ring's base address also need to be programmed to make sure the correct memory can be fetched when the DMA descriptor ring is located beyond the 32-bit boundary. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
