- 26 Apr, 2024 18 commits
-
-
Asbjørn Sloth Tønnesen authored
Rename goto label, as the error message is specific to the fragment flags. Only compile-tested. Signed-off-by:
Asbjørn Sloth Tønnesen <ast@fiberby.net> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20240424125347.461995-3-ast@fiberby.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Asbjørn Sloth Tønnesen authored
Define extack locally, to reduce line lengths and aid future users. Only compile-tested. Signed-off-by:
-
Jakub Kicinski authored
Asbjørn Sloth Tønnesen says: ==================== net: sparx5: flower: validate control flags This series adds flower control flags validation to the sparx5 driver, and changes it from assuming that it handles all control flags, to instead reject rules if they have masked any unknown/unsupported control flags. Reviewed-by:
Daniel Machon <daniel.machon@microchip.com> Tested-by:
-
Asbjørn Sloth Tønnesen authored
Use flow_rule_is_supp_control_flags() to reject filters with unsupported control flags. In case any unsupported control flags are masked, flow_rule_is_supp_control_flags() sets a NL extended error message, and we return -EOPNOTSUPP. Only compile-tested. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Remove goto, as it's only used once, and the error message is specific to that context. Only compile tested. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Define extack locally, to reduce line lengths and aid future users. Only compile tested. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
The fragment lookup should only be performed, when at least one of the fragment flags are set. This change was deliberately not included in commit 68aba004 ("net: sparx5: flower: fix fragment flags handling") as it's only needed for future proffing the code, since "mask" is currently only set in conjunction with the fragment flags. (The 3rd flag FLOW_DIS_ENCAPSULATION is only used with "key") Only compile tested. Signed-off-by:
-
Breno Leitao authored
Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_device from the private struct by converting it into a pointer. Then use the leverage the new alloc_netdev_dummy() helper to allocate and initialize dummy devices. [1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/Signed-off-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240424161108.3397057-1-leitao@debian.orgSigned-off-by:
-
Jakub Kicinski authored
Simon Horman says: ==================== net: microchip: Correct spelling in comments Correct spelling in comments in Microchip drivers. Flagged by codespell. v1: https://lore.kernel.org/r/20240419-lan743x-confirm-v1-0-2a087617a3e5@kernel.org ==================== Link: https://lore.kernel.org/r/20240424-lan743x-confirm-v2-0-f0480542e39f@kernel.orgSigned-off-by:
-
Simon Horman authored
Correct spelling in comments, as flagged by codespell. Signed-off-by:
Simon Horman <horms@kernel.org> Reviewed-by:
-
Simon Horman authored
Correct spelling in comments, as flagged by codespell. Signed-off-by:
-
Simon Horman authored
Correct spelling in comments, as flagged by codespell. Signed-off-by:
-
Simon Horman authored
Correct spelling in comments, as flagged by codespell. Signed-off-by:
-
Hayes Wang authored
Someone complains the message appears continuously. This occurs because the device is woken from UPS mode, and the driver re-loads the firmware. When the device enters runtime suspend and cable is unplugged, the device would enter UPS mode. If the runtime resume occurs, and the device is woken from UPS mode, the driver has to re-load the firmware and causes the message. If someone wakes the device continuously, the message would be shown continuously, too. Use dev_dbg to avoid it. Note that, the function could be called before register_netdev(), so I don't use netif_info() or netif_dbg(). Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20240424084532.159649-1-hayeswang@realtek.comSigned-off-by:
-
Ma Ke authored
To avoid the failure of usbnet_get_endpoints(), we should check the return value of the usbnet_get_endpoints(). Signed-off-by:
Ma Ke <make_ruc2021@163.com> Reviewed-by:
Hariprasad Kelam <hkelam@marvell.com> Link: https://lore.kernel.org/r/20240424065634.1870027-1-make_ruc2021@163.comSigned-off-by:
-
Daniel Golle authored
Add quirk for ATS SFP-GE-T 1000Base-TX module. This copper module comes with broken TX_FAULT indicator which must be ignored for it to work. Co-authored-by:
Josef Schlehofer <pepe.schlehofer@gmail.com> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> [ rebased on top of net-next ] Signed-off-by:
Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20240423090025.29231-1-kabel@kernel.orgSigned-off-by:
-
Marek Behún authored
Enhance the quirk for Fibrestore 2.5G copper SFP module. The original commit e27aca37 ("net: sfp: add quirk for FS's 2.5G copper SFP") introducing the quirk says that the PHY is inaccessible, but that is not true. The module uses Rollball protocol to talk to the PHY, and needs a 4 second wait before probing it, same as FS 10G module. The PHY inside the module is Realtek RTL8221B-VB-CG PHY. The realtek driver recently gained support to set it up via clause 45 accesses. Signed-off-by:
-
Marek Behún authored
Update the comment for the Fibrestore SFP-10G-T module: since commit e9301af3 ("net: sfp: fix PHY discovery for FS SFP-10G-T module") we also do a 4 second wait before probing the PHY. Fixes: e9301af3 ("net: sfp: fix PHY discovery for FS SFP-10G-T module") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
- 25 Apr, 2024 22 commits
-
-
Eric Dumazet authored
I had failures with pmtu.sh selftests lately, with netns dismantles firing ref_tracking alerts [1]. After much debugging, I found that some queued rcu callbacks were delayed by minutes, because of CONFIG_RCU_LAZY=y option. Joel Fernandes had a similar issue in the past, fixed with commit 483c26ff ("net: Use call_rcu_hurry() for dst_release()") In this commit, I make sure nexthop_free_rcu() and free_fib_info_rcu() are not delayed too much because they both can release device references. tools/testing/selftests/net/pmtu.sh no longer fails. Traces were: [ 968.179860] ref_tracker: veth_A-R1@00000000d0ff3fe2 has 3/5 users at dst_alloc+0x76/0x160 ip6_dst_alloc+0x25/0x80 ip6_pol_route+0x2a8/0x450 ip6_pol_route_output+0x1f/0x30 fib6_rule_lookup+0x163/0x270 ip6_route_output_flags+0xda/0x190 ip6_dst_lookup_tail.constprop.0+0x1d0/0x260 ip6_dst_lookup_flow+0x47/0xa0 udp_tunnel6_dst_lookup+0x158/0x210 vxlan_xmit_one+0x4c2/0x1550 [vxlan] vxlan_xmit+0x52d/0x14f0 [vxlan] dev_hard_start_xmit+0x7b/0x1e0 __dev_queue_xmit+0x20b/0xe40 ip6_finish_output2+0x2ea/0x6e0 ip6_finish_output+0x143/0x320 ip6_output+0x74/0x140 [ 968.179860] ref_tracker: veth_A-R1@00000000d0ff3fe2 has 1/5 users at netdev_get_by_index+0xc0/0xe0 fib6_nh_init+0x1a9/0xa90 rtm_new_nexthop+0x6fa/0x1580 rtnetlink_rcv_msg+0x155/0x3e0 netlink_rcv_skb+0x61/0x110 rtnetlink_rcv+0x19/0x20 netlink_unicast+0x23f/0x380 netlink_sendmsg+0x1fc/0x430 ____sys_sendmsg+0x2ef/0x320 ___sys_sendmsg+0x86/0xd0 __sys_sendmsg+0x67/0xc0 __x64_sys_sendmsg+0x21/0x30 x64_sys_call+0x252/0x2030 do_syscall_64+0x6c/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 968.179860] ref_tracker: veth_A-R1@00000000d0ff3fe2 has 1/5 users at ipv6_add_dev+0x136/0x530 addrconf_notify+0x19d/0x770 notifier_call_chain+0x65/0xd0 raw_notifier_call_chain+0x1a/0x20 call_netdevice_notifiers_info+0x54/0x90 register_netdevice+0x61e/0x790 veth_newlink+0x230/0x440 __rtnl_newlink+0x7d2/0xaa0 rtnl_newlink+0x4c/0x70 rtnetlink_rcv_msg+0x155/0x3e0 netlink_rcv_skb+0x61/0x110 rtnetlink_rcv+0x19/0x20 netlink_unicast+0x23f/0x380 netlink_sendmsg+0x1fc/0x430 ____sys_sendmsg+0x2ef/0x320 ___sys_sendmsg+0x86/0xd0 .... [ 1079.316024] ? show_regs+0x68/0x80 [ 1079.316087] ? __warn+0x8c/0x140 [ 1079.316103] ? ref_tracker_free+0x1a0/0x270 [ 1079.316117] ? report_bug+0x196/0x1c0 [ 1079.316135] ? handle_bug+0x42/0x80 [ 1079.316149] ? exc_invalid_op+0x1c/0x70 [ 1079.316162] ? asm_exc_invalid_op+0x1f/0x30 [ 1079.316193] ? ref_tracker_free+0x1a0/0x270 [ 1079.316208] ? _raw_spin_unlock+0x1a/0x40 [ 1079.316222] ? free_unref_page+0x126/0x1a0 [ 1079.316239] ? destroy_large_folio+0x69/0x90 [ 1079.316251] ? __folio_put+0x99/0xd0 [ 1079.316276] dst_dev_put+0x69/0xd0 [ 1079.316308] fib6_nh_release_dsts.part.0+0x3d/0x80 [ 1079.316327] fib6_nh_release+0x45/0x70 [ 1079.316340] nexthop_free_rcu+0x131/0x170 [ 1079.316356] rcu_do_batch+0x1ee/0x820 [ 1079.316370] ? rcu_do_batch+0x179/0x820 [ 1079.316388] rcu_core+0x1aa/0x4d0 [ 1079.316405] rcu_core_si+0x12/0x20 [ 1079.316417] __do_softirq+0x13a/0x3dc [ 1079.316435] __irq_exit_rcu+0xa3/0x110 [ 1079.316449] irq_exit_rcu+0x12/0x30 [ 1079.316462] sysvec_apic_timer_interrupt+0x5b/0xe0 [ 1079.316474] asm_sysvec_apic_timer_interrupt+0x1f/0x30 [ 1079.316569] RIP: 0033:0x7f06b65c63f0 Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Joel Fernandes (Google) <joel@joelfernandes.org> Cc: Paul E. McKenney <paulmck@kernel.org> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20240423205408.39632-1-edumazet@google.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/ti/icssg/icssg_prueth.c net/mac80211/chan.c 89884459 ("wifi: mac80211: fix idle calculation with multi-link") 87f55002 ("wifi: mac80211: simplify ieee80211_assign_link_chanctx()") https://lore.kernel.org/all/20240422105623.7b1fbda2@canb.auug.org.au/ net/unix/garbage.c 1971d13f ("af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().") 4090fa37 ("af_unix: Replace garbage collection algorithm.") drivers/net/ethernet/ti/icssg/icssg_prueth.c drivers/net/ethernet/ti/icssg/icssg_common.c 4dcd0e83 ("net: ti: icssg-prueth: Fix signedness bug in prueth_init_rx_chns()") e2dc7bfd ("net: ti: icssg-prueth: Move common functions into a separate file") No adjacent changes. Signed-off-by:
-
Eric Dumazet authored
While testing TCP performance with latest trees, I saw suspect SOCKET_BACKLOG drops. tcp_add_backlog() computes its limit with : limit = (u32)READ_ONCE(sk->sk_rcvbuf) + (u32)(READ_ONCE(sk->sk_sndbuf) >> 1); limit += 64 * 1024; This does not take into account that sk->sk_backlog.len is reset only at the very end of __release_sock(). Both sk->sk_backlog.len and sk->sk_rmem_alloc could reach sk_rcvbuf in normal conditions. We should double sk->sk_rcvbuf contribution in the formula to absorb bubbles in the backlog, which happen more often for very fast flows. This change maintains decent protection against abuses. Fixes: c377411f ("net: sk_add_backlog() take rmem_alloc into account") Signed-off-by: -
Jakub Kicinski authored
Merge tag 'wireless-next-2024-04-24' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.10 The second "new features" pull request for v6.10 with changes both in stack and in drivers. This time the pull request is rather small and nothing special standing out except maybe that we have several kernel-doc fixes. Great to see that we are getting warning free wireless code (until new warnings are added). Major changes: rtl8xxxu: * enable Management Frame Protection (MFP) support rtw88: * disable unsupported interface type of mesh point for all chips, and only support station mode for SDIO chips. * tag 'wireless-next-2024-04-24' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (63 commits) wifi: mac80211: handle link ID during management Tx wifi: mac80211: handle sdata->u.ap.active flag with MLO wifi: cfg80211: add return docs for regulatory functions wifi: cfg80211: make some regulatory functions void wifi: mac80211: add return docs for sta_info_flush() wifi: mac80211: keep mac80211 consistent on link activation failure wifi: mac80211: simplify ieee80211_assign_link_chanctx() wifi: mac80211: reserve chanctx during find wifi: cfg80211: fix cfg80211 function kernel-doc wifi: mac80211_hwsim: Use wider regulatory for custom for 6GHz tests wifi: iwlwifi: mvm: Don't allow EMLSR when the RSSI is low wifi: iwlwifi: mvm: disable EMLSR when we suspend with wowlan wifi: iwlwifi: mvm: get periodic statistics in EMLSR wifi: iwlwifi: mvm: don't recompute EMLSR mode in can_activate_links wifi: iwlwifi: mvm: implement EMLSR prevention mechanism. wifi: iwlwifi: mvm: exit EMLSR upon missed beacon wifi: iwlwifi: mvm: init vif works only once wifi: iwlwifi: mvm: Add helper functions to update EMLSR status wifi: iwlwifi: mvm: Implement new link selection algorithm wifi: iwlwifi: mvm: move EMLSR/links code ... ==================== Link: https://lore.kernel.org/r/20240424100122.217AEC113CE@smtp.kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Florian Fainelli says: ==================== net: dsa: b53: Remove adjust_link b53 is now the only remaining driver that uses both PHYLIB's adjust_link and PHYLINK's mac_ops callbacks, convert entirely to PHYLINK. ==================== Link: https://lore.kernel.org/r/20240423183339.1368511-1-florian.fainelli@broadcom.comSigned-off-by:
-
Florian Fainelli authored
Convert b53 to provide its own phylink MAC operations, thus avoiding the shim layer in DSA's port.c Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20240423183339.1368511-9-florian.fainelli@broadcom.comSigned-off-by:
-
Florian Fainelli authored
Only use the PHYLINK implementation from there on now that an equivalent configuration is applied to all of the switch ports. Signed-off-by:
-
Florian Fainelli authored
And make sure this is done for the MLO_AN_PHY case, where it actually makes sense, contrary to b53_adjust_link() which only did it for fixed-PHY configurations where it does not make sense. Signed-off-by:
-
Florian Fainelli authored
Call b53_adjust_531x5_rgmii() and b53_adjust_5325_mii() from b53_phylink_mac_config() when we have a fixed PHY in preparation for removing b53_adjust_link(). Also move b53_adjust_63xx_rgmii() to b53_phylink_mac_config() where it logically belongs. Signed-off-by:
-
Florian Fainelli authored
Just like what b53_adjust_link() does, force flow control for the BCM5301X CPU port(s) by forcing rx_pause and tx_pause in b53_phylink_mac_link_up(). Preparatory step for getting rid of b53_adjust_link(). Signed-off-by:
-
Florian Fainelli authored
Takes care of doing the 5325 switch series specific MII programming and is called from b53_adjust_link() to allow the future removal of b53_adjust_link(). Signed-off-by:
-
Florian Fainelli authored
Takes care of doing the 531x5 switch series specific RGMII programming and is called from b53_adjust_link() to allow the future removal of b53_adjust_link(). Signed-off-by:
-
Florian Fainelli authored
They are not used outside of the b53_common.c file, no need to be exported. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter, wireless and bluetooth. Nothing major, regression fixes are mostly in drivers, two more of those are flowing towards us thru various trees. I wish some of the changes went into -rc5, we'll try to keep an eye on frequency of PRs from sub-trees. Also disproportional number of fixes for bugs added in v6.4, strange coincidence. Current release - regressions: - igc: fix LED-related deadlock on driver unbind - wifi: mac80211: small fixes to recent clean up of the connection process - Revert "wifi: iwlwifi: bump FW API to 90 for BZ/SC devices", kernel doesn't have all the code to deal with that version, yet - Bluetooth: - set power_ctrl_enabled on NULL returned by gpiod_get_optional() - qca: fix invalid device address check, again - eth: ravb: fix registered interrupt names Current release - new code bugs: - wifi: mac80211: check EHT/TTLM action frame length Previous releases - regressions: - fix sk_memory_allocated_{add|sub} for architectures where __this_cpu_{add|sub}* are not IRQ-safe - dsa: mv88e6xx: fix link setup for 88E6250 Previous releases - always broken: - ip: validate dev returned from __in_dev_get_rcu(), prevent possible null-derefs in a few places - switch number of for_each_rcu() loops using call_rcu() on the iterator to for_each_safe() - macsec: fix isolation of broadcast traffic in presence of offload - vxlan: drop packets from invalid source address - eth: mlxsw: trap and ACL programming fixes - eth: bnxt: PCIe error recovery fixes, fix counting dropped packets - Bluetooth: - lots of fixes for the command submission rework from v6.4 - qca: fix NULL-deref on non-serdev suspend Misc: - tools: ynl: don't ignore errors in NLMSG_DONE messages" * tag 'net-6.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (88 commits) af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc(). net: b44: set pause params only when interface is up tls: fix lockless read of strp->msg_ready in ->poll dpll: fix dpll_pin_on_pin_register() for multiple parent pins net: ravb: Fix registered interrupt names octeontx2-af: fix the double free in rvu_npc_freemem() net: ethernet: ti: am65-cpts: Fix PTPv1 message type on TX packets ice: fix LAG and VF lock dependency in ice_reset_vf() iavf: Fix TC config comparison with existing adapter TC config i40e: Report MFS in decimal base instead of hex i40e: Do not use WQ_MEM_RECLAIM flag for workqueue net: ti: icssg-prueth: Fix signedness bug in prueth_init_rx_chns() net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for MACsec macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst ethernet: Add helper for assigning packet type when dest address does not match device address macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads net: phy: dp83869: Fix MII mode failure netfilter: nf_tables: honor table dormant flag from netdev release event path eth: bnxt: fix counting packets discarded due to OOM and netpoll igc: Fix LED-related deadlock on driver unbind ... -
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linuxLinus Torvalds authored
Pull nfsd fixes from Chuck Lever: - Revert some backchannel fixes that went into v6.9-rc * tag 'nfsd-6.9-5' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: Revert "NFSD: Convert the callback workqueue to use delayed_work" Revert "NFSD: Reschedule CB operations when backchannel rpc_clnt is shut down"
-
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hidLinus Torvalds authored
Pull HID fixes from Benjamin Tissoires: - A couple of i2c-hid fixes (Kenny Levinsen & Nam Cao) - A config issue with mcp-2221 when CONFIG_IIO is not enabled (Abdelrahman Morsy) - A dev_err fix in intel-ish-hid (Zhang Lixu) - A couple of mouse fixes for both nintendo and Logitech-dj (Nuno Pereira and Yaraslau Furman) - I'm changing my main kernel email address as it's way simpler for me than the Red Hat one (Benjamin Tissoires) * tag 'for-linus-2024042501' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled HID: logitech-dj: allow mice to use all types of reports HID: i2c-hid: Revert to await reset ACK before reading report descriptor HID: nintendo: Fix N64 controller being identified as mouse MAINTAINERS: update Benjamin's email address HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
-
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains two Netfilter/IPVS fixes for net: Patch #1 fixes SCTP checksumming for IPVS with gso packets, from Ismael Luceno. Patch #2 honor dormant flag from netdev event path to fix a possible double hook unregistration. * tag 'nf-24-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: honor table dormant flag from netdev release event path ipvs: Fix checksumming on GSO of SCTP packets ==================== Link: https://lore.kernel.org/r/20240425090149.1359547-1-pablo@netfilter.orgSigned-off-by:
-
Kuniyuki Iwashima authored
syzbot reported a lockdep splat regarding unix_gc_lock and unix_state_lock(). One is called from recvmsg() for a connected socket, and another is called from GC for TCP_LISTEN socket. So, the splat is false-positive. Let's add a dedicated lock class for the latter to suppress the splat. Note that this change is not necessary for net-next.git as the issue is only applied to the old GC impl. [0]: WARNING: possible circular locking dependency detected 6.9.0-rc5-syzkaller-00007-g4d200843 #0 Not tainted ----------------------------------------------------- kworker/u8:1/11 is trying to acquire lock: ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: __unix_gc+0x40e/0xf70 net/unix/garbage.c:302 but task is already holding lock: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (unix_gc_lock){+.+.}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] unix_notinflight+0x13d/0x390 net/unix/garbage.c:140 unix_detach_fds net/unix/af_unix.c:1819 [inline] unix_destruct_scm+0x221/0x350 net/unix/af_unix.c:1876 skb_release_head_state+0x100/0x250 net/core/skbuff.c:1188 skb_release_all net/core/skbuff.c:1200 [inline] __kfree_skb net/core/skbuff.c:1216 [inline] kfree_skb_reason+0x16d/0x3b0 net/core/skbuff.c:1252 kfree_skb include/linux/skbuff.h:1262 [inline] manage_oob net/unix/af_unix.c:2672 [inline] unix_stream_read_generic+0x1125/0x2700 net/unix/af_unix.c:2749 unix_stream_splice_read+0x239/0x320 net/unix/af_unix.c:2981 do_splice_read fs/splice.c:985 [inline] splice_file_to_pipe+0x299/0x500 fs/splice.c:1295 do_splice+0xf2d/0x1880 fs/splice.c:1379 __do_splice fs/splice.c:1436 [inline] __do_sys_splice fs/splice.c:1652 [inline] __se_sys_splice+0x331/0x4a0 fs/splice.c:1634 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&u->lock){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __unix_gc+0x40e/0xf70 net/unix/garbage.c:302 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(unix_gc_lock); lock(&u->lock); lock(unix_gc_lock); lock(&u->lock); *** DEADLOCK *** 3 locks held by kworker/u8:1/11: #0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline] #0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x17c0 kernel/workqueue.c:3335 #1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline] #1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x17c0 kernel/workqueue.c:3335 #2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] #2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261 stack backtrace: CPU: 0 PID: 11 Comm: kworker/u8:1 Not tainted 6.9.0-rc5-syzkaller-00007-g4d200843 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: events_unbound __unix_gc Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __unix_gc+0x40e/0xf70 net/unix/garbage.c:302 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fixes: 47d8ac01 ("af_unix: Fix garbage collector racing against connect()") Reported-and-tested-by: syzbot+fa379358c28cc87cc307@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fa379358c28cc87cc307Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240424170443.9832-1-kuniyu@amazon.comSigned-off-by:
-
Peter Münster authored
b44_free_rings() accesses b44::rx_buffers (and ::tx_buffers) unconditionally, but b44::rx_buffers is only valid when the device is up (they get allocated in b44_open(), and deallocated again in b44_close()), any other time these are just a NULL pointers. So if you try to change the pause params while the network interface is disabled/administratively down, everything explodes (which likely netifd tries to do). Link: https://github.com/openwrt/openwrt/issues/13789 Fixes: 1da177e4 (Linux-2.6.12-rc2) Cc: stable@vger.kernel.org Reported-by:
Peter Münster <pm@a16n.net> Suggested-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
Vaclav Svoboda <svoboda@neng.cz> Tested-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/87y192oolj.fsf@a16n.netSigned-off-by:
-
Sabrina Dubroca authored
tls_sk_poll is called without locking the socket, and needs to read strp->msg_ready (via tls_strp_msg_ready). Convert msg_ready to a bool and use READ_ONCE/WRITE_ONCE where needed. The remaining reads are only performed when the socket is locked. Fixes: 121dca78 ("tls: suppress wakeups unless we have a full record") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/0b7ee062319037cf86af6b317b3d72f7bfcd2e97.1713797701.git.sd@queasysnail.netSigned-off-by:
-
Arkadiusz Kubalewski authored
In scenario where pin is registered with multiple parent pins via dpll_pin_on_pin_register(..), all belonging to the same dpll device. A second call to dpll_pin_on_pin_unregister(..) would cause a call trace, as it tries to use already released registration resources (due to fix introduced in b446631f). In this scenario pin was registered twice, so resources are not yet expected to be release until each registered pin/pin pair is unregistered. Currently, the following crash/call trace is produced when ice driver is removed on the system with installed E810T NIC which includes dpll device: WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Call Trace: ? __warn+0x7f/0x130 ? dpll_pin_ops+0x20/0x30 dpll_msg_add_pin_freq+0x37/0x1d0 dpll_cmd_pin_get_one+0x1c0/0x400 ? __nlmsg_put+0x63/0x80 dpll_pin_event_send+0x93/0x140 dpll_pin_on_pin_unregister+0x3f/0x100 ice_dpll_deinit_pins+0xa1/0x230 [ice] ice_remove+0xf1/0x210 [ice] Fix by adding a parent pointer as a cookie when creating a registration, also when searching for it. For the regular pins pass NULL, this allows to create separated registration for each parent the pin is registered with. Fixes: b446631f ("dpll: fix dpll_xa_ref_*_del() for multiple registrations") Signed-off-by:
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by:
-
Geert Uytterhoeven authored
As interrupts are now requested from ravb_probe(), before calling register_netdev(), ndev->name still contains the template "eth%d", leading to funny names in /proc/interrupts. E.g. on R-Car E3: 89: 0 0 GICv2 93 Level eth%d:ch22:multi 90: 0 3 GICv2 95 Level eth%d:ch24:emac 91: 0 23484 GICv2 71 Level eth%d:ch0:rx_be 92: 0 0 GICv2 72 Level eth%d:ch1:rx_nc 93: 0 13735 GICv2 89 Level eth%d:ch18:tx_be 94: 0 0 GICv2 90 Level eth%d:ch19:tx_nc Worse, on platforms with multiple RAVB instances (e.g. R-Car V4H), all interrupts have similar names. Fix this by using the device name instead, like is done in several other drivers: 89: 0 0 GICv2 93 Level e6800000.ethernet:ch22:multi 90: 0 1 GICv2 95 Level e6800000.ethernet:ch24:emac 91: 0 28578 GICv2 71 Level e6800000.ethernet:ch0:rx_be 92: 0 0 GICv2 72 Level e6800000.ethernet:ch1:rx_nc 93: 0 14044 GICv2 89 Level e6800000.ethernet:ch18:tx_be 94: 0 0 GICv2 90 Level e6800000.ethernet:ch19:tx_nc Rename the local variable dev_name, as it shadows the dev_name() function, and pre-initialize it, to simplify the code. Fixes: 32f012b8 ("net: ravb: Move getting/requesting IRQs in the probe() method") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://lore.kernel.org/r/cde67b68adf115b3cf0b44c32334ae00b2fbb321.1713944647.git.geert+renesas@glider.beSigned-off-by:
-
