- Nov 17, 2022
-
-
Hangbin Liu authored
kernel test robot reported warnings when build bonding module with make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/net/bonding/: from ../drivers/net/bonding/bond_main.c:35: In function ‘fortify_memcpy_chk’, inlined from ‘iph_to_flow_copy_v4addrs’ at ../include/net/ip.h:566:2, inlined from ‘bond_flow_ip’ at ../drivers/net/bonding/bond_main.c:3984:3: ../include/linux/fortify-string.h:413:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of f ield (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 413 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function ‘fortify_memcpy_chk’, inlined from ‘iph_to_flow_copy_v6addrs’ at ../include/net/ipv6.h:900:2, inlined from ‘bond_flow_ip’ at ../drivers/net/bonding/bond_main.c:3994:3: ../include/linux/fortify-string.h:413:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of f ield (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 413 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is because we try to copy the whole ip/ip6 address to the flow_key, while we only point the to ip/ip6 saddr. Note that since these are UAPI headers, __struct_group() is used to avoid the compiler warnings. Reported-by:kernel test robot <lkp@intel.com> Fixes: c3f83241 ("net: Add full IPv6 addresses to flow_keys") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Link: https://lore.kernel.org/r/20221115142400.1204786-1-liuhangbin@gmail.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Alexandru Tachici authored
An external PHY needs settling time after power up or reset. In the bind() function an mdio bus is registered. If at this point the external PHY is still initialising, no valid PHY ID will be read and on phy_find_first() the bind() function will fail. If an external PHY is present, wait the maximum time specified in 802.3 45.2.7.1.1. Fixes: 05b35e7e ("smsc95xx: add phylib support") Signed-off-by:
Alexandru Tachici <alexandru.tachici@analog.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221115114434.9991-2-alexandru.tachici@analog.com Signed-off-by:
-
Enrico Sau authored
Add the following Telit LE910C4-WWX composition: 0x103a: rmnet Signed-off-by:
Enrico Sau <enrico.sau@gmail.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20221115105859.14324-1-enrico.sau@gmail.com Signed-off-by:
-
- Nov 16, 2022
-
-
Wang Yufen authored
kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove(). Fixes: d3cbb907 ("netdevsim: add ACL trap reporting cookie as a metadata") Signed-off-by:Wang Yufen <wangyufen@huawei.com> Cc: Jiri Pirko <jiri@mellanox.com> Link: https://lore.kernel.org/r/1668504625-14698-1-git-send-email-wangyufen@huawei.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Gleb Mazovetskiy authored
On embedded systems with little memory and no relevant security concerns, it is beneficial to reduce the size of the table. Reducing the size from 2^16 to 2^8 saves 255 KiB of kernel RAM. Makes the table size configurable as an expert option. The size was previously increased from 2^8 to 2^16 in commit 4c2c8f03 ("tcp: increase source port perturb table to 2^16"). Signed-off-by:
Gleb Mazovetskiy <glex.spb@gmail.com> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
sk->sk_user_data has multiple users, which are not compatible with each other. Writers must synchronize by grabbing the sk->sk_callback_lock. l2tp currently fails to grab the lock when modifying the underlying tunnel socket fields. Fix it by adding appropriate locking. We err on the side of safety and grab the sk_callback_lock also inside the sk_destruct callback overridden by l2tp, even though there should be no refs allowing access to the sock at the time when sk_destruct gets called. v4: - serialize write to sk_user_data in l2tp sk_destruct v3: - switch from sock lock to sk_callback_lock - document write-protection for sk_user_data v2: - update Fixes to point to origin of the bug - use real names in Reported/Tested-by tags Cc: Tom Parkin <tparkin@katalix.com> Fixes: 3557baab ("[L2TP]: PPP over L2TP driver core") Reported-by:
Haowei Yan <g1042620637@gmail.com> Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by:
-
Yuan Can authored
A problem about insmod thunderbolt-net failed is triggered with following log given while lsmod does not show thunderbolt_net: insmod: ERROR: could not insert module thunderbolt-net.ko: File exists The reason is that tbnet_init() returns tb_register_service_driver() directly without checking its return value, if tb_register_service_driver() failed, it returns without removing property directory, resulting the property directory can never be created later. tbnet_init() tb_register_property_dir() # register property directory tb_register_service_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without remove property directory Fix by remove property directory when tb_register_service_driver() returns error. Fixes: e69b6c02 ("net: Add support for networking over Thunderbolt cable") Signed-off-by:Yuan Can <yuancan@huawei.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
David S. Miller authored
Shang XiaoJing says: ==================== net: microchip: Fix potential null-ptr-deref due to create_singlethread_workqueue() There are some functions call create_singlethread_workqueue() without checking ret value, and the NULL workqueue_struct pointer may causes null-ptr-deref. Will be fixed by this patch. ==================== Signed-off-by: -
Shang XiaoJing authored
sparx_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. So as sparx5_start(). Fixes: af4b1102 ("net: sparx5: add ethtool configuration and statistics support") Fixes: b37a1bae ("net: sparx5: add mactable support") Signed-off-by:Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by:
-
Shang XiaoJing authored
lan966x_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: lan966x_stats_init() create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. Fixes: 12c2d0a5 ("net: lan966x: add ethtool configuration and statistics") Signed-off-by:Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
- Nov 15, 2022
-
-
Vladimir Oltean authored
In the initial commit dc452a47 ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time. There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything. Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage Fixes: 7f297314 ("net: dsa: make tagging protocols connect to individual switches from a tree") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Saeed Mahameed <saeed@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221114143551.1906361-1-vladimir.oltean@nxp.com Signed-off-by:
-
Wei Yongjun authored
x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak. Fixes: cb101ed2 ("x25: Handle undersized/fragmented skbs") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/20221114110519.514538-1-weiyongjun@huaweicloud.com Signed-off-by:
-
Liu Jian authored
If ag71xx_hw_enable() fails, call phylink_disconnect_phy() to clean up. And if phylink_of_phy_connect() fails, nothing needs to be done. Compile tested only. Fixes: 892e0915 ("net: ag71xx: port to phylink") Signed-off-by:
Liu Jian <liujian56@huawei.com> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20221114095549.40342-1-liujian56@huawei.com Signed-off-by:
-
Ido Schimmel authored
The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fixes: 27973793 ("net: bridge: Fix VLANs memory leak") Reported-by:Vlad Buslov <vladbu@nvidia.com> Tested-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Link: https://lore.kernel.org/r/20221114084509.860831-1-idosch@nvidia.com Signed-off-by:
-
Paolo Abeni authored
Hao Lan says: ==================== net: hns3: This series bugfix for the HNS3 ethernet driver. This series includes some bugfix for the HNS3 ethernet driver. Patch 1# fix incorrect hw rss hash type of rx packet. Fixes: 79664077 ("net: hns3: support RXD advanced layout") Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb") Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet") Patch 2# fix return value check bug of rx copybreak. Fixes: e74a726d ("net: hns3: refactor hns3_nic_reuse_page()") Fixes: 99f6b5fb ("net: hns3: use bounce buffer when rx page can not be reused") Patch 3# net: hns3: fix setting incorrect phy link ksettings for firmware in resetting process Fixes: f5f2b3e4 ("net: hns3: add support for imp-controlled PHYs") Fixes: c5ef83cb ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config") Fixes: 2312e050 ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo") ==================== Link: https://lore.kernel.org/r/20221114082048.49450-1-lanhao@huawei.com Signed-off-by:
-
Guangbin Huang authored
Currently, if driver is in phy-imp(phy controlled by imp firmware) mode, as driver did not update phy link ksettings after initialization process or not update advertising when getting phy link ksettings from firmware, it may set incorrect phy link ksettings for firmware in resetting process. So fix it. Fixes: f5f2b3e4 ("net: hns3: add support for imp-controlled PHYs") Fixes: c5ef83cb ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config") Fixes: 2312e050 ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo") Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Jie Wang authored
The refactoring of rx copybreak modifies the original return logic, which will make this feature unavailable. So this patch fixes the return logic of rx copybreak. Fixes: e74a726d ("net: hns3: refactor hns3_nic_reuse_page()") Fixes: 99f6b5fb ("net: hns3: use bounce buffer when rx page can not be reused") Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
-
Jian Shen authored
Currently, the HNS3 driver reports the rss hash type of each packet based on the rss hash tuples set. It always reports PKT_HASH_TYPE_L4, without checking the type of current packet. It's incorrect. Fixes it by reporting it base on the packet type. Fixes: 79664077 ("net: hns3: support RXD advanced layout") Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb") Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Aminuddin Jamaluddin authored
Sleep time is added to ensure the phy to be ready after loopback bit was set. This to prevent the phy loopback test from failing. Fixes: 020a45af ("net: phy: marvell: add Marvell specific PHY loopback") Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Signed-off-by:
Aminuddin Jamaluddin <aminuddin.jamaluddin@intel.com> Link: https://lore.kernel.org/r/20221114065302.10625-1-aminuddin.jamaluddin@intel.com Signed-off-by:
-
Yuan Can authored
The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Shay Agroskin <shayagr@amazon.com> Link: https://lore.kernel.org/r/20221114025659.124726-1-yuancan@huawei.com Signed-off-by:
-
Cong Wang authored
sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue. Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module") Reported-by:
<syzbot+278279efdd2730dd14bf@syzkaller.appspotmail.com> Reported-by:
shaozhengchao <shaozhengchao@huawei.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Tom Herbert <tom@herbertland.com> Signed-off-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20221114005119.597905-1-xiyou.wangcong@gmail.com Signed-off-by:
-
- Nov 14, 2022
-
-
Yuan Can authored
A problem about ionic create debugfs failed is triggered with the following log given: [ 415.799514] debugfs: Directory 'ionic' with parent '/' already present! The reason is that ionic_init_module() returns ionic_bus_register_driver() directly without checking its return value, if ionic_bus_register_driver() failed, it returns without destroy the newly created debugfs, resulting the debugfs of ionic can never be created later. ionic_init_module() ionic_debugfs_create() # create debugfs directory ionic_bus_register_driver() pci_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when ionic_bus_register_driver() returns error. Fixes: fbfb8031 ("ionic: Add hardware init and device commands") Signed-off-by:Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20221113092929.19161-1-yuancan@huawei.com Signed-off-by:
-
Amit Cohen authored
FDB entries that perform VXLAN encapsulation with an IPv6 underlay hold a reference on a resource - the KVDL entry where the IPv6 underlay destination IP is stored. For that, the driver maintains two hash tables: 1. Maps IPv6 to KVDL index 2. Maps {MAC, FID index} to IPv6 address When a FDB entry is removed, the second table is used to find the relevant IPv6 address and the first table is used to remove the reference count and free the index if is not used anymore. In order for a packet to be forwarded to a single remote VTEP, FDB entries need to be configured at both the bridge and VXLAN devices' FDB tables. Both entries are squashed into one {MAC, VLAN/VNI} -> IP entry in the hardware. Therefore, in case one entry is removed, the entry will be removed from the hardware and the remaining entry will be unmarked with 'offload' flag since it is not offloaded anymore. For example, the two FDB entries should be added to allow packets to be forwarded via vx10: $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff self static dst 2001:db8:5::1 $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff master static vlan 10 When one entry will be removed, the second one will not be offloaded anymore. When the first entry (in VXLAN FDB) will be removed / will not be offloaded anymore, the two mappings in IPv6 hash tables will be removed. In case that the second entry is removed before the first one, unexpected warnings[1][2] will be shown in user space as a result of removing the first entry. The issue is that not offloaded entry is removed, the driver tries to search the relevant entries in the hash tables, does not find them and therefore warns. Do not handle removing of not offloaded VXLAN FDB entries, as they were already removed when the offload flag was removed. [1]: WARNING: CPU: 1 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum_nve.c:914 mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Call Trace: <TASK> mlxsw_sp_port_fdb_tunnel_uc_op+0x6cf/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> [2]: WARNING: CPU: 0 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3035 mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Call Trace: <TASK> ? mlxsw_sp_port_fdb_tun_uc_op6_sfd_write+0x5c1/0x610 [mlxsw_spectrum] mlxsw_sp_port_fdb_tunnel_uc_op+0x6ec/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Fixes: 0860c764 ("mlxsw: spectrum_nve: Keep track of IPv6 addresses used by FDB entries") Signed-off-by:Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/c186de8cbd28e3eb661e06f31f7f2f2dff30020f.1668184350.git.petrm@nvidia.com Signed-off-by:
-
Vladimir Oltean authored
There are multi-generational drivers like mv88e6xxx which have code like this: int mv88e6xxx_port_hwtstamp_get(struct dsa_switch *ds, int port, struct ifreq *ifr) { if (!chip->info->ptp_support) return -EOPNOTSUPP; ... } DSA wants to deny PTP timestamping on the master if the switch supports timestamping too. However it currently relies on the presence of the port_hwtstamp_get() callback to determine PTP capability, and this clearly does not work in that case (method is present but returns -EOPNOTSUPP). We should not deny PTP on the DSA master for those switches which truly do not support hardware timestamping. Create a dsa_port_supports_hwtstamp() method which actually probes for support by calling port_hwtstamp_get() and seeing whether that returned -EOPNOTSUPP or not. Fixes: f685e609 ("net: dsa: Deny PTP on master if switch supports it") Link: https://patchwork.kernel.org/project/netdevbpf/patch/20221110124345.3901389-1-festevam@gmail.com/ Reported-by:Fabio Estevam <festevam@gmail.com> Reported-by:
Steffen Bätz <steffen@innosonix.de> Signed-off-by:
Fabio Estevam <festevam@denx.de> Signed-off-by:
-
Wei Yongjun authored
MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch calls free_netdev() to fix it since netdev_priv is used after unregister. Fixes: 13adac03 ("net: mhi_net: Register wwan_ops for link creation") Signed-off-by:
-
David S. Miller authored
Ziyang Xuan says: ==================== octeon_ep: fix several bugs in exception paths Find several obvious bugs during code review in exception paths. Provide this patchset to fix them. Not tested, just compiled. ==================== Signed-off-by: -
Ziyang Xuan authored
octep_get_mac_addr() can fail because send mbox message failed. If this happens, octep_dev->mac_addr will be zero. It should not continue to initialize. Add exception handling for octep_get_mac_addr() to fix it. Fixes: 862cd659 ("octeon_ep: Add driver framework and device initialization") Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by:
-
Ziyang Xuan authored
When occur unsupported_dev and mbox init errors, it did not free oct->conf and iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem. Add kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under unsupported_dev and mbox init errors to fix the problem. Fixes: 862cd659 ("octeon_ep: Add driver framework and device initialization") Signed-off-by:
-
Ziyang Xuan authored
octep_get_link_status() can fail because send mbox message failed, then octep_get_link_status() will return ret less than 0. Excute octep_link_up() as long as ret is not equal to 0 in octep_open() now. That is not correct. The value type of link.state is enum octep_ctrl_net_state. Positive value represents up. Excute octep_link_up() when ret is bigger than 0. Fixes: 862cd659 ("octeon_ep: Add driver framework and device initialization") Signed-off-by:
-
Ziyang Xuan authored
octep_napi_add() and octep_napi_enable() are all after netif_set_real_num_{tx,rx}_queues() in octep_open(), so it is unnecessary napi rollback under set_queues_err. Delete them to fix it. Fixes: 37d79d05 ("octeon_ep: add Tx/Rx processing and interrupt support") Signed-off-by: -
Gaosheng Cui authored
When pci_register_driver failed, we need to remove debugfs, which will caused a resource leak, fix it. Resource leak logs as follows: [ 52.184456] debugfs: Directory 'bnxt_en' with parent '/' already present! Fixes: cabfb09d ("bnxt_en: add debugfs support for DIM") Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Zhengchao Shao authored
When connecting to client timeout, disconnect client for twice in chnl_net_open(). Remove one. Compile tested only. Fixes: 2aa40aef ("caif: Use link layer MTU instead of fixed MTU") Signed-off-by:
-
Chuang Wang authored
hlist_for_each_entry_rcu() has built-in RCU and lock checking. Pass cond argument to hlist_for_each_entry_rcu() to silence false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled. Execute as follow: ip link add link eth0 type macvlan mode source macaddr add <MAC-ADDR> The rtnl_lock is held when macvlan_hash_lookup_source() or macvlan_fill_info_macaddr() are called in the non-RCU read side section. So, pass lockdep_rtnl_is_held() to silence false lockdep warning. Fixes: 79cf79ab ("macvlan: add source mode") Signed-off-by:
Chuang Wang <nashuiliang@gmail.com> Signed-off-by:
-
Wang ShaoBo authored
We should not release reference by put_device() before calling device_initialize(). Fixes: e7d1d4d9 ("mISDN: fix possible memory leak in mISDN_register_device()") Signed-off-by:
Wang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by:
-
Zhengchao Shao authored
When liquidio driver open failed, it doesn't release resources. Compile tested only. Fixes: 5b07aee1 ("liquidio: MSIX support for CN23XX") Fixes: dbc97bfd ("net: liquidio: Add missing null pointer checks") Signed-off-by:
-
- Nov 11, 2022
-
-
Jeremy Kerr authored
We're currently hitting the WARN_ON in mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); This may be hit if we expire a flow before sending the first packet it contains - as we will not be pairing the increment of release_count (performed on flow release) with the i2c lock operation (only performed on actual TX). To fix this, only release a flow if we've encountered it previously (ie, dev_flow_state does not indicate NEW), as we will mark the flow as ACTIVE at the same time as accounting for the i2c lock operation. We also need to add an INVALID flow state, to indicate when we've done the release. Fixes: f5b8abf9 ("mctp i2c: MCTP I2C binding driver") Reported-by:Jian Zhang <zhangjian.3032@bytedance.com> Tested-by:
Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20221110053135.329071-1-jk@codeconstruct.com.au Signed-off-by:
-
Yu Liao authored
'aead_req' and 'aead_send' is allocated but not freed in default switch case. This commit fixes the potential memory leak by freeing them under the situation. Note that the default cases here should never be reached as they'd mean we allowed offloading an unsupported algorithm. Fixes: ea7a9d88 ("net/tls: Use cipher sizes structs") Signed-off-by:
Yu Liao <liaoyu15@huawei.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Link: https://lore.kernel.org/r/20221110090329.2036382-1-liaoyu15@huawei.com Signed-off-by:
-
Mohd Faizal Abdul Rahim authored
When stmmac_xdp_release() is called, there is a possibility that tx function is still running on other queues which will lead to tx queue timed out and reset adapter. This commit ensure that tx function is not running xdp before release flow continue to run. Fixes: ac746c85 ("net: stmmac: enhance XDP ZC driver level switching performance") Signed-off-by:
Song Yoong Siang <yoong.siang.song@intel.com> Signed-off-by:
Mohd Faizal Abdul Rahim <faizal.abdul.rahim@intel.com> Signed-off-by:
Noor Azura Ahmad Tarmizi <noor.azura.ahmad.tarmizi@intel.com> Link: https://lore.kernel.org/r/20221110064552.22504-1-noor.azura.ahmad.tarmizi@linux.intel.com Signed-off-by:
-
Michael Sit Wei Hong authored
Current driver code will read device tree node information, and set default values if there is no info provided. This is not done in non-OF devices leading to SGMII fifo depths being set to the smallest size. This patch sets the value to the default value of the PHY as stated in the PHY datasheet. Fixes: 4dc08dcc ("net: phy: dp83867: introduce critical chip default init for non-of platform") Signed-off-by:
Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Reviewed-by:
-
Yuan Can authored
A problem about hinic create debugfs failed is triggered with the following log given: [ 931.419023] debugfs: Directory 'hinic' with parent '/' already present! The reason is that hinic_module_init() returns pci_register_driver() directly without checking its return value, if pci_register_driver() failed, it returns without destroy the newly created debugfs, resulting the debugfs of hinic can never be created later. hinic_module_init() hinic_dbg_register_debugfs() # create debugfs directory pci_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when pci_register_driver() returns error. Fixes: 253ac3a9 ("hinic: add support to query sq info") Signed-off-by:
-
