- 28 Sep, 2021 1 commit
-
-
MichelleJin authored
When rhashtable_init() fails, it returns -EINVAL. However, since error return value of rhashtable_init is not checked, it can cause use of uninitialized pointers. So, fix unhandled errors of rhashtable_init. Signed-off-by:
MichelleJin <shjy180909@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 27 Sep, 2021 39 commits
-
-
David S. Miller authored
Florian Fainelli says: ==================== net: bcmgenet: support for flow control This patch series adds support for flow control to the GENET driver, the first 2 patches remove superfluous code, the 3rd one does re-organize code a little bit and the 4th one ads the support for flow control proper. ====================
-
Doug Berger authored
This commit extends the supported ethtool operations to allow MAC level flow control to be configured for the bcmgenet driver. The ethtool utility can be used to change the configuration of auto-negotiated symmetric and asymmetric modes as well as manually configuring support for RX and TX Pause frames individually. Signed-off-by:
Doug Berger <opendmb@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Doug Berger authored
This commit separates out the MAC configuration that occurs on a PHY state change into a function named bcmgenet_mac_config(). This allows the function to be called directly elsewhere. Signed-off-by:
-
Doug Berger authored
The PHY state machine has been fixed to only call the adjust_link callback when the link state has changed. Therefore the old link state variables are no longer needed to detect a change in link state. This commit effectively reverts commit 5ad6e6c5 ("net: bcmgenet: improve bcmgenet_mii_setup()") Signed-off-by:
-
Doug Berger authored
The bcmgenet_mii_setup() function is registered as the adjust_link callback from the phylib for the GENET driver. The phylib always sets the netif_carrier according to phydev->link prior to invoking the adjust_link callback, so there is no need to repeat that in the link down case within the network driver. Signed-off-by:
-
David S. Miller authored
Linus Walleij says: ==================== RTL8366(RB) cleanups part 1 This is a first set of patches making the RTL8366RB work out of the box with a default OpenWrt userspace. We achieve bridge port isolation with the first patch, and the next 5 patches removes the very weird VLAN set-up with one VLAN with PVID per port that has been in this driver in all vendor trees and in OpenWrt for years. The switch is now managed the way a modern bridge/DSA switch shall be managed. After these patches are merged, I will send the next set which adds new features, some which have circulated before. ChangeLog v4->v5: - Drop the patch disabling 4K VLAN. - Drop the patch forcing VLAN0 untagged. - Fix a semantic bug in the filer enablement code. ==================== Signed-off-by: -
Linus Walleij authored
We don't need a message for every VLAN association, dbg is fine. The message about adding the DSA or CPU port to a VLAN is directly misleading, this is perfectly fine. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
We were checking that the MC (member config) was != 0 for some reason, all we need to check is that the config has no ports, i.e. no members. Then it can be recycled. This must be some misunderstanding. Fixes: 4ddcaf1e ("net: dsa: rtl8366: Properly clear member config") Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Linus Walleij authored
The max VLAN number with non-4K VLAN activated is 15, and the range is 0..15. Not 16. The impact should be low since we by default have 4K VLAN and thus have 4095 VLANs to play with in this switch. There will not be a problem unless the code is rewritten to only use 16 VLANs. Fixes: d8652956 ("net: dsa: realtek-smi: Add Realtek SMI driver") Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
Linus Walleij authored
While we were defining one VLAN per port for isolating the ports the port_vlan_filtering() callback was implemented to enable a VLAN on the port + 1. This function makes no sense, not only is it incomplete as it only enables the VLAN, it doesn't do what the callback is supposed to do, which is to selectively enable and disable filtering on a certain port. Implement the correct callback: we have two registers dealing with filtering on the RTL9366RB, so we implement an ASIC-specific callback and implement filering using the register bit that makes the switch drop frames if the port is not in the VLAN member set. The DSA documentation Documentation/networking/switchdev.rst states: When the bridge has VLAN filtering enabled and a PVID is not configured on the ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge has VLAN filtering enabled and a PVID exists on the ingress port, untagged and priority-tagged packets must be accepted and forwarded according to the bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering disabled, the presence/lack of a PVID should not influence the packet forwarding decision. To comply with this, we add two arrays of bool in the RTL8366RB state that keeps track of if filtering and PVID is enabled or not for each port. We then add code such that whenever filtering or PVID changes, we update the filter according to the specification. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: Alvin Šipraga <alsi@bang-olufsen.dk> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: DENG Qingfang <dqfext@gmail.com> Signed-off-by:
-
Linus Walleij authored
This hacky default VLAN setup was done in order to direct packets to the right ports and provide port isolation, both which we now support properly using custom tags and proper bridge port isolation. We can drop the custom VLAN code and leave all VLAN handling alone, as users expect things to be. We can also drop ds->configure_vlan_while_not_filtering = false; and let the core deal with any VLANs it wants. Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by:
-
DENG Qingfang authored
Use port isolation registers to configure bridge offloading. Tested on the D-Link DIR-685, switching between ports and sniffing ports to make sure no packets leak. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Reviewed-by:
DENG Qingfang <dqfext@gmail.com> Signed-off-by:
-
David S. Miller authored
Leon Romanovsky says: ==================== Move devlink_register to be last devlink command This is second version of patch series https://lore.kernel.org/netdev/cover.1628599239.git.leonro@nvidia.com/ The main change is addition of delayed notification logic that will allowed us to delete devlink_params_publish API (future series will remove it completely) and conversion of all drivers to have devlink_register being last commend. The series itself is pretty straightforward, except liquidio driver which performs initializations in various workqueues without proper locks. That driver doesn't hole device_lock and it is clearly broken for any parallel driver core flows (modprobe + devlink + PCI reset will 100% crash it). In order to annotate devlink_register() will lockdep of holding device_lock, I added workaround in this driver. Thanks ---------------------- From previous cover letter: Hi Dave and Jakub, This series prepares code to remove devlink_reload_enable/_disable API and in order to do, we move all devlink_register() calls to be right before devlink_reload_enable(). The best place for such a call should be right before exiting from the probe(). This is done because devlink_register() opens devlink netlink to the users and gives them a venue to issue commands before initialization is finished. 1. Some drivers were aware of such "functionality" and tried to protect themselves with extra locks, state machines and devlink_reload_enable(). Let's assume that it worked for them, but I'm personally skeptical about it. 2. Some drivers copied that pattern, but without locks and state machines. That protected them from reload flows, but not from any _set_ routines. 3. And all other drivers simply didn't understand the implications of early devlink_register() and can be seen as "broken". ==================== Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Indirectly this change fixes the commit mentioned below where devlink_unregister() was prematurely removed. Fixes: db4278c5 ("devlink: Make devlink_register to be void") Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. Signed-off-by:
-
Leon Romanovsky authored
Open user space access to the devlink after driver is probed. Signed-off-by:
-
Leon Romanovsky authored
Open access to the devlink interface when the driver fully initialized. Signed-off-by:
-
Leon Romanovsky authored
Make sure that devlink is open to receive user input when all parameters are initialized. Signed-off-by:
-
Leon Romanovsky authored
The change of devlink_alloc() to accept device makes sure that device is fully initialized and device_register() does nothing except allowing users to use that devlink instance. Such change ensures that no user input will be usable till that point and it eliminates the need to worry about internal locking as long as devlink_register is called last since all accesses to the devlink are during initialization. This change fixes the following lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ #27 Not tainted ------------------------------------------------------ devlink/265 is trying to acquire lock: ffff8880133c2bc0 (&dev->intf_state_mutex){+.+.}-{3:3}, at: mlx5_unload_one+0x1e/0xa0 [mlx5_core] but task is already holding lock: ffffffff8362b468 (devlink_mutex){+.+.}-{3:3}, at: devlink_nl_pre_doit+0x2b/0x8d0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (devlink_mutex){+.+.}-{3:3}: __mutex_lock+0x149/0x1310 devlink_register+0xe7/0x280 mlx5_devlink_register+0x118/0x480 [mlx5_core] mlx5_init_one+0x34b/0x440 [mlx5_core] probe_one+0x480/0x6e0 [mlx5_core] pci_device_probe+0x2a0/0x4a0 really_probe+0x1cb/0xba0 __driver_probe_device+0x18f/0x470 driver_probe_device+0x49/0x120 __driver_attach+0x1ce/0x400 bus_for_each_dev+0x11e/0x1a0 bus_add_driver+0x309/0x570 driver_register+0x20f/0x390 0xffffffffa04a0062 do_one_initcall+0xd5/0x400 do_init_module+0x1c8/0x760 load_module+0x7d9d/0xa4b0 __do_sys_finit_module+0x118/0x1a0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&dev->intf_state_mutex){+.+.}-{3:3}: __lock_acquire+0x2999/0x5a40 lock_acquire+0x1a9/0x4a0 __mutex_lock+0x149/0x1310 mlx5_unload_one+0x1e/0xa0 [mlx5_core] mlx5_devlink_reload_down+0x185/0x2b0 [mlx5_core] devlink_reload+0x1f2/0x640 devlink_nl_cmd_reload+0x6c3/0x10d0 genl_family_rcv_msg_doit+0x1e9/0x2f0 genl_rcv_msg+0x27f/0x4a0 netlink_rcv_skb+0x11e/0x340 genl_rcv+0x24/0x40 netlink_unicast+0x433/0x700 netlink_sendmsg+0x6fb/0xbe0 sock_sendmsg+0xb0/0xe0 __sys_sendto+0x192/0x240 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(devlink_mutex); lock(&dev->intf_state_mutex); lock(devlink_mutex); lock(&dev->intf_state_mutex); *** DEADLOCK *** 3 locks held by devlink/265: #0: ffffffff836371d0 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff83637288 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x31a/0x4a0 #2: ffffffff8362b468 (devlink_mutex){+.+.}-{3:3}, at: devlink_nl_pre_doit+0x2b/0x8d0 stack backtrace: CPU: 0 PID: 265 Comm: devlink Not tainted 5.14.0-rc2+ #27 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 check_noncircular+0x268/0x310 ? print_circular_bug+0x460/0x460 ? __kernel_text_address+0xe/0x30 ? alloc_chain_hlocks+0x1e6/0x5a0 __lock_acquire+0x2999/0x5a40 ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 ? add_lock_to_list.constprop.0+0x6c/0x530 lock_acquire+0x1a9/0x4a0 ? mlx5_unload_one+0x1e/0xa0 [mlx5_core] ? lock_release+0x6c0/0x6c0 ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 ? lock_is_held_type+0x98/0x110 __mutex_lock+0x149/0x1310 ? mlx5_unload_one+0x1e/0xa0 [mlx5_core] ? lock_is_held_type+0x98/0x110 ? mlx5_unload_one+0x1e/0xa0 [mlx5_core] ? find_held_lock+0x2d/0x110 ? mutex_lock_io_nested+0x1160/0x1160 ? mlx5_lag_is_active+0x72/0x90 [mlx5_core] ? lock_downgrade+0x6d0/0x6d0 ? do_raw_spin_lock+0x12e/0x270 ? rwlock_bug.part.0+0x90/0x90 ? mlx5_unload_one+0x1e/0xa0 [mlx5_core] mlx5_unload_one+0x1e/0xa0 [mlx5_core] mlx5_devlink_reload_down+0x185/0x2b0 [mlx5_core] ? netlink_broadcast_filtered+0x308/0xac0 ? mlx5_devlink_info_get+0x1f0/0x1f0 [mlx5_core] ? __build_skb_around+0x110/0x2b0 ? __alloc_skb+0x113/0x2b0 devlink_reload+0x1f2/0x640 ? devlink_unregister+0x1e0/0x1e0 ? security_capable+0x51/0x90 devlink_nl_cmd_reload+0x6c3/0x10d0 ? devlink_nl_cmd_get_doit+0x1e0/0x1e0 ? devlink_nl_pre_doit+0x72/0x8d0 genl_family_rcv_msg_doit+0x1e9/0x2f0 ? __lock_acquire+0x15e2/0x5a40 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? mutex_lock_io_nested+0x1160/0x1160 ? security_capable+0x51/0x90 genl_rcv_msg+0x27f/0x4a0 ? genl_get_cmd+0x3c0/0x3c0 ? lock_acquire+0x1a9/0x4a0 ? devlink_nl_cmd_get_doit+0x1e0/0x1e0 ? lock_release+0x6c0/0x6c0 netlink_rcv_skb+0x11e/0x340 ? genl_get_cmd+0x3c0/0x3c0 ? netlink_ack+0x930/0x930 genl_rcv+0x24/0x40 netlink_unicast+0x433/0x700 ? netlink_attachskb+0x750/0x750 ? __alloc_skb+0x113/0x2b0 netlink_sendmsg+0x6fb/0xbe0 ? netlink_unicast+0x700/0x700 ? netlink_unicast+0x700/0x700 sock_sendmsg+0xb0/0xe0 __sys_sendto+0x192/0x240 ? __x64_sys_getpeername+0xb0/0xb0 ? do_sys_openat2+0x10a/0x370 ? down_write_nested+0x150/0x150 ? do_user_addr_fault+0x215/0xd50 ? __x64_sys_openat+0x11f/0x1d0 ? __x64_sys_open+0x1a0/0x1a0 __x64_sys_sendto+0xdc/0x1b0 ? syscall_enter_from_user_mode+0x1d/0x50 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f50b50b6b3a Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 c3 0f 1f 44 00 00 55 48 83 ec 30 44 89 4c RSP: 002b:00007fff6c0d3f38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f50b50b6b3a RDX: 0000000000000038 RSI: 000055763ac08440 RDI: 0000000000000003 RBP: 000055763ac08410 R08: 00007f50b5192200 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 000055763ac08410 R15: 000055763ac08440 mlx5_core 0000:00:09.0: firmware version: 4.8.9999 mlx5_core 0000:00:09.0: 0.000 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x255 link) mlx5_core 0000:00:09.0 eth1: Link up Fixes: a6f3b623 ("net/mlx5: Move devlink registration before interfaces load") Signed-off-by: -
Leon Romanovsky authored
Refactor the code to make sure that devlink_register() is the last command during initialization stage. Signed-off-by:
-
Leon Romanovsky authored
Separate devlink registrations and traps registrations so devlink will be registered when driver is fully initialized. Signed-off-by:
-
Leon Romanovsky authored
This change prevents from users to access device before devlink is fully configured. This change allows us to delete call to devlink_params_publish() and impossible check during unregister flow. Signed-off-by:
-
Leon Romanovsky authored
Move devlink_registration routine to be the last command, when the device is fully initialized. Signed-off-by:
-
Leon Romanovsky authored
Move devlink registration to be the last command in device activation, so it opens the driver to accept such devlink commands from the user when it is fully initialized. Signed-off-by:
-
Leon Romanovsky authored
Move devlink_register to be the last command in the initialization sequence. Signed-off-by:
-
Leon Romanovsky authored
The liquidio driver is broken by design. It initialize PCI devices in separate delayed works. It causes to the situation where device lock is dropped during initialize and remove sequences. That lock is part of driver/core and needed to protect from races during init, destroy and bus invocations. In addition to lack of locking protection, it has incorrect order of destroy flows and very questionable synchronization scheme based on atomic_t. This change doesn't fix that driver but makes sure that rest of the netdev subsystem doesn't suffer from such basic protection by adding device_lock over devlink_*() APIs and by moving devlink_register() to be last command in setup_nic_devices(). Signed-off-by:
-
Leon Romanovsky authored
Move devlink_register() to be last command in devlink configuration sequence, so no user space access will be possible till devlink instance is fully operable. As part of this change, the devlink_params_publish call is removed as not needed. This change fixes forgotten devlink_params_unpublish() too. Signed-off-by:
-
Leon Romanovsky authored
The devlink core code notified users about add/remove objects without relation if this object can be accessible or not. In this patch we unify such user visible notifications in one place. Signed-off-by:
-
Arnd Bergmann authored
clang-14 does not like the custom offsetof() macro in vsc7326: drivers/net/ethernet/chelsio/cxgb/vsc7326.c:597:3: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] HW_STAT(RxUnicast, RxUnicastFramesOK), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/chelsio/cxgb/vsc7326.c:594:56: note: expanded from macro 'HW_STAT' { reg, (&((struct cmac_statistics *)NULL)->stat_name) - (u64 *)NULL } Rewrite this to use the version provided by the kernel. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
gcc-10 and later warn about a theoretical array overrun when accessing priv->int_name_rx_irq[i] with an out of bounds value of 'i': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_request_irq_multi_msi': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3528:17: error: 'snprintf' argument 4 may overlap destination object 'dev' [-Werror=restrict] 3528 | snprintf(int_name, int_name_len, "%s:%s-%d", dev->name, "tx", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3404:60: note: destination object referenced by 'restrict'-qualified argument 1 was declared here 3404 | static int stmmac_request_irq_multi_msi(struct net_device *dev) | ~~~~~~~~~~~~~~~~~~~^~~ The warning is a bit strange since it's not actually about the array bounds but rather about possible string operations with overlapping arguments, but it's not technically wrong. Avoid the warning by adding an extra bounds check. Fixes: 8532f613 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") Link: https://lore.kernel.org/all/20210421134743.3260921-1-arnd@kernel.org/Reported-by:kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Christian Lamparter authored
of_get_mac_address() reads the same "local-mac-address" property. ... But goes above and beyond by checking the MAC value properly. printk+message seems outdated too, so let's put dev_err in the queue. Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Yang Li authored
Use resource_size function on resource object instead of explicit computation. Clean up coccicheck warning: ./drivers/net/ethernet/microchip/sparx5/sparx5_main.c:237:19-22: ERROR: Missing resource_size with iores [ idx ] Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Cai Huoqing authored
Replacing kmalloc/kfree/dma_map_single/dma_unmap_single() with dma_alloc_coherent/dma_free_coherent() helps to reduce code size, and simplify the code, and coherent DMA will not clear the cache every time. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
