- 27 Sep, 2021 39 commits
-
-
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:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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:
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by:
Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by:
-
Mianhan Liu authored
tcp_nv.c hasn't use any macro or function declared in mm.h. Thus, these files can be removed from tcp_nv.c safely without affecting the compilation of the net module. Signed-off-by:
Mianhan Liu <liumh1@shanghaitech.edu.cn> Signed-off-by:
-
Cai Huoqing authored
Use dma_xxx_xxx() instead of pci_xxx_xxx(), because the pci function wrappers are not called here. Signed-off-by:
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by:
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by:
-
Cai Huoqing authored
Use dma_map_single() instead of pci_map_single(), because the pci function wrappers are not called here. Signed-off-by:
-
Cai Huoqing authored
Use dma_map_single() instead of pci_map_single(), because only dma_map_single() is called here. Signed-off-by:
-
Cai Huoqing authored
Use dma_xxx_xxx() instead of pci_xxx_xxx(), because the pci function wrappers are not called here. Signed-off-by:
-
Jakub Kicinski authored
Commit 3765996e ("napi: fix race inside napi_enable") fixed an ordering bug in napi_enable() and made the napi_enable() diverge from napi_disable(). The state transitions done on disable are not symmetric to enable. There is no known bug in napi_disable() this is just refactoring. Eric suggests we can also replace msleep(1) with a more opportunistic usleep_range(). Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Min Li authored
rsmu (Renesas Synchronization Management Unit ) driver is located in drivers/mfd and responsible for creating multiple devices including clockmatrix phc, which will then use the exposed regmap and mutex handle to access i2c/spi bus. Signed-off-by:
Min Li <min.li.xe@renesas.com> Signed-off-by:
-
Petr Machata authored
The purpose of this test is to verify that after a short activity passes, the reported time is reasonable: not zero (which could be reported by mistake), and not something outrageous (which would be indicative of an issue in used units). However, the idle time is reported in units of clock_t, or hundredths of second. If the initial sequence of commands is very quick, it is possible that the idle time is reported as just flat-out zero. When this test was recently enabled in our nightly regression, we started seeing spurious failures for exactly this reason. Therefore buffer the delay leading up to the test with a sleep, to make sure there is no legitimate way of reporting 0. Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
- 26 Sep, 2021 1 commit
-
-
David S. Miller authored
Kiran Kumar K says: ==================== adding KPU profile changes for GTPU and custom Adding changes to limit the KPU processing for GTPU headers to parse packet up to L4 and added changes to variable length headers to parse LA as part of PKIND action. ==================== Signed-off-by:
-
