summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
7 daysipv4: use rcu_assign_pointer() in rt_flush_dev()Xuanqiang Luo
rt_flush_dev() replaces rt->dst.dev with blackhole_netdev on uncached routes. The field is also exposed as dst.dev_rcu, and existing readers use dst_dev_rcu(). Use rcu_assign_pointer() for the replacement, as dst_dev_put() already does for the same field. Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260708060537.17188-2-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: skbuff: optimization of net_zcopy_get() call in pskb_carve helpersYun Lu
Commit 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") introduced two calls of net_zcopy_get(skb_zcopy(skb)). In fact, skb_zcopy() has already been executed once before. When calling net_zcopy_get(), skb_zcopy() always returns skb_uarg(skb), which results in adding some unnecessary instructions in skb_zcopy. So, change these two calls to directly use skb_uarg(skb) instead of skb_zcopy. In addition, also use net_zcopy_get() instead of refcount_inc() in pskb_expand_head() for code consistency. No functional change intended. Signed-off-by: Yun Lu <luyun@kylinos.cn> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260708055454.9167-1-luyun_611@163.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysslab: silence sparse warning with type-based partitioningMarco Elver
Sparse does not know __builtin_infer_alloc_token() and complains: sparse: sparse: undefined identifier '__builtin_infer_alloc_token' Fix it by using a dummy variant of __kmalloc_token() if __CHECKER__ is defined. Fixes: feb662d9168b ("slab: support for compiler-assisted type-based slab cache partitioning") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607110912.nZTqfCrH-lkp@intel.com/ Signed-off-by: Marco Elver <elver@google.com> Link: https://patch.msgid.link/20260721092005.1986693-1-elver@google.com Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
7 daysdrm/xe/migrate: Revamp PAT index selection for migrate PTEsSanjay Yadav
Improve PAT index selection logic in xe_migrate.c to avoid unnecessary coherency overhead when host-side memory is uncached. Previously, we defaulted to XE_CACHE_WB, which enforces 2-way coherency and may trigger cacheline pulls from CPU even when host-side memory is never dirty. This change introduces xe_migrate_pat_index() to choose the appropriate PAT index based on the actual TTM caching mode of the buffer object being mapped. For iGPUs with WC host mappings, we now prefer XE_CACHE_NONE to skip coherency snoops. For compressed PTEs on newer platforms, we select XE_CACHE_NONE_COMPRESSION. This avoids unnecessary cache traffic for uncached host mappings. v6: (sashiko) - Only apply the BO's host-side caching for system-memory PTEs. v5: (Matt A) - Simplify emit_pte() to derive caching from res->bo directly, removing the separate bo parameter - Leave changes in __xe_migrate_update_pgtables() and build_pt_update_batch_sram() - Fix comment about page-walker coherency in xe_migrate_pat_index() v4: - Keep xe_migrate_prepare_vm() on XE_CACHE_WB since page tables require page-walker coherency. - Pass BO into emit_pte() and select PAT attributes from the BO's TTM caching mode. Assisted-by: Github-Copilot:claude-opus-4.8 Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710083004.1546599-2-sanjay.kumar.yadav@intel.com
7 daysgtp: parse extension headers before reading inner protocolZhixing Chen
GTPv1-U packets may carry a chain of extension headers before the inner IP packet. The receive path already parses and skips these extension headers, but it currently reads the inner protocol before doing so. As a result, the first extension header byte is interpreted as the inner IP version. Packets with extension headers are then dropped before PDP lookup. Parse the extension header chain before calling gtp_inner_proto(), so the inner protocol is read from the actual inner IP header. Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family") Signed-off-by: Zhixing Chen <running910@gmail.com> Link: https://patch.msgid.link/20260708042244.120898-1-running910@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysrds: drop incoming messages that cross network namespace boundariesAldo Ariel Panzardo
rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison. Fixes: c809195f5523 ("rds: clean up loopback rds_connections on netns deletion") Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com> Reviewed-by: Allison Henderson <achender@kernel.org> Tested-by: Allison Henderson <achender@kernel.org> Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260708024314.601139-1-achender@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysMerge branch 'udp-fix-fou-gue-over-multicast'Paolo Abeni
Anton Danilov says: ==================== udp: fix FOU/GUE over multicast UDP encapsulation (FOU, GUE) has never worked correctly with multicast destination addresses. When a FOU-encapsulated packet arrives at a multicast address, it enters __udp4_lib_mcast_deliver() / __udp6_lib_mcast_deliver() which call consume_skb() on packets that need resubmission to the inner protocol handler, silently dropping them instead. The unicast delivery paths handle this correctly by propagating the return value up to ip[6]_protocol_deliver_rcu() for resubmission, but the multicast paths were never updated to support UDP encapsulation resubmit. This causes silent packet loss for FOU/GRETAP tunnels configured with multicast remote addresses (both IPv4 and IPv6). Reproducing the issue (IPv4): ip netns add ns_a && ip netns add ns_b ip link add veth0 netns ns_a type veth peer name veth1 netns ns_b ip -n ns_a addr add 10.0.0.1/24 dev veth0 && ip -n ns_a link set veth0 up ip -n ns_b addr add 10.0.0.2/24 dev veth1 && ip -n ns_b link set veth1 up ip -n ns_a route add 239.0.0.0/8 dev veth0 ip -n ns_b route add 239.0.0.0/8 dev veth1 # Disable early demux to expose the issue (otherwise it's partially masked) ip netns exec ns_b sysctl -w net.ipv4.ip_early_demux=0 # Join multicast group on receiver ip -n ns_b addr add 239.0.0.1/32 dev veth1 autojoin # Sender: GRETAP with FOU encap ip -n ns_a link add eoudp0 type gretap \ remote 239.0.0.1 local 10.0.0.1 \ encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1 ip -n ns_a link set eoudp0 up ip -n ns_a addr add 192.168.99.1/24 dev eoudp0 # Receiver: FOU listener + GRETAP ip netns exec ns_b ip fou add port 4797 ipproto 47 ip -n ns_b link add eoudp0 type gretap \ remote 239.0.0.1 local 10.0.0.2 \ encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1 ip -n ns_b link set eoudp0 up ip -n ns_b addr add 192.168.99.2/24 dev eoudp0 # Static neigh: ARP replies can't traverse unidirectional mcast tunnel recv_mac=$(ip -n ns_b link show eoudp0 | awk '/ether/{print $2}') ip -n ns_a neigh add 192.168.99.2 lladdr $recv_mac dev eoudp0 # Test: ping through the FOU/GRETAP tunnel ip netns exec ns_a ping -c 100 192.168.99.2 # -> without this patch: 0 packets received on eoudp0 # -> with this patch: all packets received on eoudp0 IPv6 (using fou6 + ip6gretap) exhibits the same silent drop with a different fix (see 1/2 for the sign-of-ret difference between ip_protocol_deliver_rcu() and ip6_protocol_deliver_rcu()). AI assistance (Claude, claude-opus-4-6) was used during root cause analysis of the kernel source code (tracing the call chain from udp[6]_queue_rcv_skb through encap_rcv to ip[6]_protocol_deliver_rcu, comparing unicast/GSO/multicast paths) and during patch and selftest authoring. v5: https://lore.kernel.org/netdev/cover.1783218197.git.littlesmilingcloud@gmail.com/ v4: https://lore.kernel.org/netdev/cover.1782945956.git.littlesmilingcloud@gmail.com/ v3: https://lore.kernel.org/netdev/cover.1777934869.git.littlesmilingcloud@gmail.com/ v2: https://lore.kernel.org/netdev/ad_dal164gVmImWl@dau-home-pc/ v1 (RFC): https://lore.kernel.org/netdev/ad7MsSJOuUU6EGwS@dau-home-pc/ ==================== Link: https://patch.msgid.link/cover.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysselftests: net: add FOU multicast encapsulation resubmit testAnton Danilov
Add a selftest to verify that FOU-encapsulated packets addressed to a multicast destination are correctly resubmitted to the inner protocol handler (GRE) via the UDP multicast delivery path. Both IPv4 and IPv6 paths are tested. The test creates two network namespaces connected by a veth pair with a FOU/GRETAP (IPv4) and FOU/ip6gretap (IPv6) tunnel using multicast remote addresses (239.0.0.1 and ff0e::1). Ping is sent through each tunnel and received packets are counted on the receiver's tunnel interface. The veth pair is created directly inside the namespaces to avoid possible name collisions with devices in the root namespace. Static neighbor entries are configured on the sender because ARP/ND replies from the receiver cannot traverse the unidirectional multicast tunnel back to the sender. The early demux optimization (net.ipv4.ip_early_demux, which controls both IPv4 and IPv6) is disabled on the receiver to force packets through __udp4_lib_mcast_deliver() / __udp6_lib_mcast_deliver(), which is the code path being tested. Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/a5b65f092d22a12b52fc536c0565b948cd8ecae3.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysudp: fix encapsulation packet resubmit in multicast deliverAnton Danilov
When a UDP encapsulation socket (e.g., FOU) receives a multicast packet, __udp4_lib_mcast_deliver() and __udp6_lib_mcast_deliver() call consume_skb() when udp_queue_rcv_skb() returns a positive value. A positive return value from udp_queue_rcv_skb() indicates that the encap_rcv handler (e.g., fou_udp_recv) has consumed the UDP header and wants the packet to be resubmitted to the IP protocol handler for further processing (e.g., as a GRE packet). The unicast paths handle this correctly by propagating the return value up to ip_protocol_deliver_rcu() / ip6_protocol_deliver_rcu() for resubmission. However, the multicast paths destroy the packet via consume_skb() instead of resubmitting it, causing silent packet loss. This affects any UDP encapsulation (FOU, GUE) combined with multicast destination addresses. Fix this by returning the value from udp_queue_rcv_skb() when it is positive, matching the behavior of the corresponding unicast paths. Note the sign difference between IPv4 and IPv6: - IPv4: udp_unicast_rcv_skb() returns -ret, and ip_protocol_deliver_rcu() resubmits when ret < 0 (using -ret as the protocol number). - IPv6: udp6_unicast_rcv_skb() returns ret, and ip6_protocol_deliver_rcu() resubmits when ret > 0 (using ret as the nexthdr). Both mcast paths now follow the same convention as their respective unicast paths. Suggested-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/5372ccac062193147e02b991d5328a5c3fa3a85a.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet/mlx5e: Use sender devcom for MPV master-upManjunath Patil
After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery. Fixes: bf11485f8419 ("net/mlx5: Register mlx5e priv to devcom in MPV mode") Assisted-by: Codex:gpt-5 Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com> Cc: stable@vger.kernel.org # 6.7+ Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707233911.3651139-1-manjunath.b.patil@oracle.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysMerge branch 'net-add-adin1140-support'Paolo Abeni
Ciprian Regus says: ==================== net: Add ADIN1140 support This series introduces support for the ADIN1140 (also called AD3306) 10BASE-T1S single port MACPHY. The device integrates the MAC and PHY in the same package. The communication with the host CPU is done through an SPI interface, using the Open Alliance TC6 protocol for control and data transactions. As a result, the oa_tc6 framework is used to implement the communication with the device (register accesses and Ethernet frame RX/TX). The MAC and PHY are connected internally using an MII and MDIO bus. The PHY is a half duplex 10Mbps device, which implements both the PLCA RS (IEEE 802.3 clause 148) and CSMA/CD methods of accessing the Ethernet medium. The 10BASE-T1S standard allows multiple PHY devices to be connected (in parallel) on the same single twisted pair network segment, so PLCA can be configured in order to provide a fair access scheme to all the nodes and reduce the jitter introduced by the unordered CSMA/CD transmits. The PHY's internal register map can be accessed using the direct MDIO mode of the OA TC6. The control, status, phy id 1 & 2 C22 registers are mapped to the 0xFF00 - 0xFF03 range. As for C45 addressable devices, the PHY has PCS, PMA and PLCA blocks. The oa_tc6 framework patches are changes that would make the library usable by the subsequent ADIN1140 MAC driver. The protected mode patch is required because the ADIN1140 only allows protected mode OA TC6 control transactions, which the oa_tc6 framework doesn't currently implement. The OA_TC6_BROKEN_PHY quirk patch is required in order to allow the MAC driver to have a custom implementation for the mii_bus access methods as a workaround for hardware issues: 1. The OA TC6 standard defines the direct and indirect access modes for MDIO transactions. The ADIN1140 incorrectly advertises indirect mode only (supported capabilities register - 0x2, bit 9), while actually implementing just the direct mode. We cannot rely on the CAP register to choose an access method (which oa_tc6 does by default, even though it only implements the direct mode), so the driver has to use its own. 2. The ADIN1140 cannot access the C22 register space of the internal PHY, while the PHY is busy receiving frames. If that happens, the CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the data transfer will stop. Those two registers configure settings for the transfer protocol between the MAC and host, so the value for some of their subfields shouldn't be changed while the netdev is up. Since we know the PHY is internal, the MAC driver can implement a custom mii_bus, which can intercept C22 accesses. Most of the registers mapped in the 0x0 - 0x3 range (the only ones the PHY offers) are read only, and their value can be read from somewhere else (e.g the PHYID 1 & 2 have the same value as 0x1 in the MAC memory map). C45 accesses do not cause this issue, so we can properly implement them. Even though they have different driver, the MAC one cannot function without the PHY driver, since the PHY is not compatible with the generic c22 driver. As such CONFIG_ADIN1140 selects CONFIG_ADIN1140_PHY. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> ==================== Link: https://patch.msgid.link/20260708-adin1140-driver-v5-0-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: adi: Add a driver for the ADIN1140 MACPHYCiprian Regus
Add a driver for ADIN1140. The device is a 10BASE-T1S MAC-PHY (integrated in the same package) that connects to a CPU over an SPI bus, and implements the Open Alliance TC6 protocol for control and frame transfers. As such, this driver relies on oa_tc6 for the communication with the device. The device has an alternative name (AD3306), so the driver can be probed using one of the two compatible strings. For control transactions, ADIN1140 only implements the protected mode. The driver has a custom implementation for the mii_bus access methods as a workaround for hardware issues: 1. The OA TC6 standard defines the direct and indirect access modes for MDIO transactions. The ADIN1140 incorrectly advertises indirect mode only (supported capabilities register - 0x2, bit 9), while actually implementing just the direct mode. We cannot rely on the CAP register to choose an access method (which oa_tc6 does by default, even though it only implements the direct mode), so the driver has to use its own. 2. The ADIN1140 cannot access the C22 register space of the internal PHY, while the PHY is busy receiving frames. If that happens, the CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the data transfer will stop. Those two registers configure settings for the transfer protocol between the MAC and host, so the value for some of their subfields shouldn't be changed while the netdev is up. Since we know the PHY is internal, the MAC driver can implement a custom mii_bus, which can intercept C22 accesses. Most of the registers mapped in the 0x0 - 0x3 range (the only ones the PHY offers) are read only, and their value can be read from somewhere else (e.g the PHYID 1 & 2 have the same value as 0x1 in the MAC memory map). For the fields that are R/W (loopback and AN/reset) in the control register, the PHY driver already implements the set_loopback() and config_aneg() functions. The C22 write function of the driver is a no-op and is used to protect against the ioctl MDIO access path. C45 accesses do not cause this issue, so we can properly implement them. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-13-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: phy: Add support for the ADIN1140 PHYCiprian Regus
Add a driver for the ADIN1140's internal 10BASE-T1S PHY. The device doesn't implement autonegotiation, so the link is always reported as being up. The device implements both C22 and C45 MDIO access methods, but can only be discovered over C22, since the C45 MMD devices lack the MDIO_DEVID1 and MDIO_DEVID2 registers. The indirect C45 over C22 feature is not supported. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-12-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: phy: microchip-t1s: use generic C45 MMD access helpersCiprian Regus
Replace the driver specific lan865x_phy_read_mmd() and lan865x_phy_write_mmd() with the shared genphy_read_mmd_c45() and genphy_write_mmd_c45() helpers. No functional change. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-11-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: phy: add generic helpers for direct C45 MMD accessCiprian Regus
Some PHYs support direct C45 register access but not C22 indirect MMD access (registers 0xD and 0xE). When discovered via C22, phylib routes MMD access through the indirect path, which won't work on these devices. Add genphy_read_mmd_c45() and genphy_write_mmd_c45() as read_mmd/ write_mmd callbacks that bypass the C22 indirect path and use the bus C45 accessors directly. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-10-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Add new register address definesCiprian Regus
Add macro defines for the CONFIG2 register and the MMS1 memory map. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-9-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Use the read_mms/write_mms functions for C45Ciprian Regus
Accessing PHY MMD devices requires control transactions to registers in a memory map other than 0. Replace the current formatting of the register addresses with the oa_tc6_{read,write}_register_mms() functions. While we're here, introduce the mms variable to store the memory map returned by oa_tc6_get_phy_c45_mms() instead of ret, in order to improve the code readability. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-8-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Add read_mms/write_mms register access functionsCiprian Regus
The Open Alliance TC6 standard defines multiple memory maps for the MAC-PHY's register space. These are used to separate standard, vendor and PHY MMD specific registers. Define register access functions that allow the caller to specify the MMS. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-7-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Add the OA_TC6_ prefix to standard registersCiprian Regus
The OA TC6 standard registers are currently exported in a header file. Add the OA_TC6_ prefix to the register address and subfield mask macros to avoid future naming conflicts. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-6-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Export standard defined registersCiprian Regus
Move defines for standard Open Alliance TC6 register addresses and subfields in the oa_tc6's header. As such, other ethernet drivers that rely on oa_tc6 can use them directly. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-5-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Export the C45 access functionsCiprian Regus
The C45 access functions can still be used by some Ethernet drivers which set the OA_TC6_BROKEN_PHY flag. Export them. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-4-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: add OA_TC6_BROKEN_PHY quirk flagCiprian Regus
Some MAC-PHY devices need custom MDIO bus access functions to work around hardware issues. Add the OA_TC6_BROKEN_PHY quirk flag so drivers can opt in to skip oa_tc6's internal PHY init and manage the PHY themselves. When the flag is set, oa_tc6 skips MDIO bus registration, PHY discovery and PHY connection, leaving these to the driver. Drivers that do not set the flag retain the existing behavior. Update lan865x and the framework documentation accordingly. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-3-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: ethernet: oa_tc6: Handle the OA TC6 SPI protected modeCiprian Regus
Implement the OA TC6 standard defined protected mode for control (register access) transactions. In addition to the current register access formats the oa_tc6 driver handles, 1's complement values of the data field are included (by both the host and the MACPHY) in the SPI transfer frames. This feature acts as an integrity check. Control write transactions look like this: |<- 32 bits ->|<--- data_size --->|<- 32 bits ->| MOSI: | ctrl header | reg write data | ignored | MISO: | (discard) | echoed ctrl hdr | echoed data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Control read transaction: |<- 32 bits ->|<--- 32 bits --> |<- data_size ->| MOSI: | ctrl header | ignored ... | MISO: | (discard) | echoed ctrl hdr | reg read data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Register data format ("reg write data" and "reg read data"): Unprotected: | W1 (normal) | W2 (normal) | ... | Wx (normal) | Protected: | W1 (normal) | W1 (complement) | ... | Wx (normal) | Wx (complement)| The protected mode state can be read from the bit 5 of CONFIG0 (0x4) register, and this setting is usually only configured during the MACPHY's reset (depending on the device it can be done by setting the state of a pin). We can read the protected mode configuration before any other register access and since the SPI transfer is initially sized for an unprotected read, the MACPHY's complement words are never clocked out and no checking is required. The data transactions (Ethernet frames) remain unchanged. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-2-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysdt-bindings: net: Add ADIN1140Ciprian Regus
The ADIN1140 is a single port 10BASE-T1S Ethernet controller that includes both the MAC and a PHY in the same package. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-1-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysplatform/x86: uniwill-laptop: Remove single color keyboard detectionArmin Wolf
Having a ad-hoc device whitelist inside uniwill_kbd_led_init() to work around unreliable KBD_WHITE_ONLY values conflicts with the idea of the device descriptor infrastructure. Remove the ad-hoc device whitelist and use the device descriptor infrastructure instead. Suggested-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260720132611.374073-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
7 daysplatform/x86: uniwill-laptop: Split uniwill_kbd_led_init()Armin Wolf
The function uniwill_kbd_led_init() is quite large and doing multiple things at once: - general hardware initialisation - single color keyboard backlight registration - RGB keyboard backlight registration Move the last two things into separate functions to increase the maintainability of uniwill_kbd_led_init(). Suggested-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260720132611.374073-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
7 daysopenvswitch: fix GSO userspace truncation underflowKyle Zeng
OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it. Fixes: f2a4d086ed4c ("openvswitch: Add packet truncation support.") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng <kylebot@openai.com> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260707221635.27489-1-kylebot@openai.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysdrm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar
Wa_16030862157: Update Bandwidth Calculation to account for 16channel memory config. v2: Logical separation of changes (Suraj, Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 68859 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-3-uma.shankar@intel.com
7 daysdrm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar
Wa_16030862157: Interpret 0xF populated-channel count as 16 The register MEM_SS_INFO_GLOBAL [Number of populated channels] field definition is updated with an encoding for 16 channels. For 16-channel configuration, program 1111b. A programmed value of 1111b must be interpreted as 16 channels for memory bandwidth calculations. The MEM_SS_INFO_GLOBAL populated-channel field is only 4 bits and cannot encode 16, so on Xe3p the BIOS programs the saturated field value (0xf) to indicate the fully-populated 16-channel config (4 memory controllers x 4 channels). Interpret it as 16 and let the bandwidth math handle the larger channel count. v2: Limit the WA only till NVL (Suraj) Logical separation of WA (Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 79482 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-2-uma.shankar@intel.com
7 daysirqchip/gic-v3-its: Fix grammar and replace a bit number with its symbolKemeng Shi
Fix grammatical errors in comments and simplify the comment about reading GITS_BASER_INDIRECT to check two-level support. Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721063241.52549-3-shikemeng@huaweicloud.com
7 daysirqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()Kemeng Shi
When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721063241.52549-2-shikemeng@huaweicloud.com
7 daysnet: sparx5: configure TAS port link speedRobert Marko
On the TSN and RED variants of LAN969x and SparX-5i TAS (Time-Aware Shaper) is present in the silicon. Currently, the driver does not use configure it at all, which means that the TAS_PROFILE_CONFIG.LINK_SPEED[1] value is left at the default of 3 which means that its configured for 1 Gbps. So, running iperf between two 10G switch ports will result in only 940-ish Mbps while we should be getting around 9.3 Gbps. Correctly populating the TAS_PROFILE_CONFIG.LINK_SPEED[1] with the current port speed fixes this issue and we achieve around 9.4 Gbps between two 10G switch ports. So, port the TAS port link speed setting from the vendor BSP 6.18 kernel[2] [1] https://microchip-ung.github.io/lan969x-industrial_reginfo/reginfo_LAN969x-Industrial.html?select=hsch,tas_profile_cfg,tas_profile_config,link_speed [2] https://github.com/microchip-ung/linux/tree/bsp-6.18-2026 Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20260707170531.1129866-1-robert.marko@sartura.hr Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysALSA: hda/realtek - Add quirk for Dell Pro QC1255Kailang Yang
Vendor want to add more machine on this workaround. Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255") Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/e13d08e96ac449b6994d56dfe6ce3f5c@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
7 daysarm64: versal-net: Switch Versal NET to firmware clock interfaceMichal Simek
Switch Versal NET from using fixed clocks to the firmware-based clock interface (versal-net-clk.dtsi). This enables proper clock management through the platform firmware instead of relying on static fixed-clock definitions. Add DT macro headers for Versal NET and base Versal clocks, power domains and mandatory resets required by the clock dtsi. Link: https://patch.msgid.link/77e6234f6cef3f78fb1c6c97142fa8055982e14e.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
7 daysdt-bindings: clock: versal-clk: Fix Versal NET clock validationMichal Simek
The Versal NET clock controller compatible is specified as: compatible = "xlnx,versal-net-clk", "xlnx,versal-clk"; with xlnx,versal-clk listed as fallback. The original binding had two separate if/then blocks - one matching xlnx,versal-clk (2 clocks) and another matching xlnx,versal-net-clk (3 clocks). Since both compatible strings are present, both conditions matched simultaneously and JSON Schema applied the more restrictive 2-clock constraint, causing false "too long" validation errors for Versal NET. Define clock-names at the top-level and use if/then only to constrain the clock count (2 for Versal, 3 for Versal NET). Add a dedicated example for the Versal NET 3-clock configuration. Fixes: 39118392d19a ("dt-bindings: Remove alt_ref from versal") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/202e448e57cf979e1b5be61da0bad7778defdd4e.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
7 daysdt-bindings: clock: Move xlnx,zynqmp-clk to its own schemaMichal Simek
The ZynqMP clock controller binding shares only #clock-cells with the Versal bindings. Move it to a dedicated xlnx,zynqmp-clk.yaml schema. Also remove "(Optional clock)" from clock description because it is visible from schema itself. Also update versal-firmware example to match changes in xlnx,zynqmp-firmware.yaml. Suggested-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/973a8a5441cf13622594b95dd0dd20a5f42ccece.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
7 daysdt-bindings: clock: versal-clk: Fix mio_clk index range in clock-names patternMichal Simek
The clock-names pattern "^mio_clk[00-77]+.*$" was intended to constrain the MIO index to the valid range 00..77 (ZynqMP has 78 MIO pins), but a regex character class cannot express a multi-digit decimal range. Replace the bogus character class with an explicit alternation that enumerates the two-digit decimal values 00..77. Fixes: 03d4a1004053 ("dt-bindings: clock: versal: Convert the xlnx,zynqmp-clk.txt to yaml") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/e742b7da70c2bf10650a81e537f1b90d76799416.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
7 daysdt-bindings: firmware: xilinx: Add missing example for ZynqMPMichal Simek
Document clock-controller under zynqmp-firmware in the binding example so ZynqMP DTs validate against xlnx,versal-clk.yaml (Versal example already did). Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/12dba601a8b631e565dd98e52a89b0ec18fcdce2.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
7 daysnet: airoha: fix MIB stats collection to be losslessAniket Negi
REG_FE_GDM_MIB_CLEAR after every read creates a race window where packets arriving between read and clear are lost from statistics. Switch to a delta-based approach instead: - 64-bit H+L registers (ok pkts/bytes, E64..L1023): read absolute hardware total directly into a local variable; clamp with max(new, old) to prevent torn-read regression when the counter carries between the two reads. - 32-bit registers (drops, bc, mc, errors, runt, long): accumulate (u32)(curr - prev) into a 64-bit software counter; unsigned subtraction handles wrap-around transparently. - tx/rx_len[0] ([0,64] bucket): combines RUNT_CNT (32-bit, delta via tx_runt/rx_runt) and E64_CNT (64-bit, absolute) into a single local accumulator; max(new, old) applied here too to guard against a torn read of E64 when the RUNT accumulator is unchanged between polls. MIB counters are zeroed by the SCU FE reset (EN7581_FE_RST) asserted in airoha_hw_init() at module load, so no explicit MIB clear is needed in airoha_fe_init(). Merge airoha_dev_get_hw_stats() into airoha_update_hw_stats() and move stats_lock inside. Plain spin_lock() is correct: the function is only called from ndo_get_stats64() in process context. Each dev refreshes only its own MIB counters; sibling devs on a shared GDM3/4 port are polled when their own netdev is queried. Fixes: 8f4695fb67b2 ("net: airoha: better handle MIBs for GDM ports with multiple devs attached") Signed-off-by: Aniket Negi <aniket.negi03@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260707152639.105628-1-aniket.negi03@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysmm/slub: prevent pfmemalloc objects from entering the barnShengming Hu
kmem_cache_return_sheaf() may refill a partially consumed sheaf before placing it in the barn. Without an explicit restriction, this refill may draw objects from pfmemalloc slabs and consume emergency reserves. Add __GFP_NOMEMALLOC so that returned sheaves are refilled only from non-pfmemalloc slabs. Also add __GFP_NOWARN, as suggested by Hao Li, because this refill is a best-effort attempt and failure is acceptable. If the refill fails, flush and free the sheaf instead. Fixes: 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with sheaves") Cc: stable@vger.kernel.org Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Hao Li <hao.li@linux.dev> Link: https://patch.msgid.link/20260721084522552ZPa16p1SRj3PYat3sqxuN@zte.com.cn Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
7 daysMerge branch 'geneve-make-geneve_fill_info-rtnl-less'Paolo Abeni
Eric Dumazet says: ==================== geneve: make geneve_fill_info() RTNL-less This series makes geneve_fill_info() independent of the RTNL lock by converting the device configuration to an RCU-protected pointer. Historically, geneve_changelink() updated the device configuration by copying the new configuration over the old one using memcpy() under RTNL. To prevent the transmit/receive data paths from reading torn values during the copy, geneve_quiesce() was used to pause the data path and wait for a synchronize_net(), causing packet loss and latency. By converting the configuration to an RCU-protected pointer, we can perform atomic updates via RCU swap. This allows data path readers to safely access the configuration locklessly under RCU read lock, and removes the need to stop the data path during changelink. With the RCU infrastructure in place, geneve_fill_info() is then updated to read the configuration under RCU read lock, removing its dependency on RTNL. v1: https://lore.kernel.org/netdev/20260701120454.3533252-1-edumazet@google.com/T/#m887804321856d9b5c7142107e81b52553e60e6ab ==================== Link: https://patch.msgid.link/20260707145331.3717941-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysgeneve: make geneve_fill_info() RTNL independentEric Dumazet
Now that geneve->cfg is an RCU-protected pointer, update geneve_fill_info() to read the configuration under RCU read lock instead of relying on RTNL. Also add const qualifiers to the dereferenced pointers where appropriate and fix local variable declaration ordering. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260707145331.3717941-4-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysgeneve: convert config to RCU-protected pointerEric Dumazet
geneve_changelink() currently updates configuration by copying it over the old one using memcpy() under RTNL, forcing data path pause via geneve_quiesce() and synchronize_net() to avoid reading torn values. Convert geneve->cfg to an RCU-protected pointer, allowing lockless and safe reads under RCU read lock without synchronization overhead. Key changes: - Introduced geneve_config_alloc/free() helpers for lifecycle. - geneve_configure() allocates config and publishes it via RCU. - Setting dev->priv_destructor = geneve_free_dev handles config cleanup if register_netdevice() fails or during netdev unregistration. - geneve_changelink() performs RCU swap; old config is freed via call_rcu_hurry(). - Allocates new dst_cache during changelink to prevent pcpu sharing. - Removed geneve_quiesce/unquiesce() and synchronize_net() from changelink. - Added rcu_barrier() to module exit to wait for pending callbacks. - Updated data path to use rcu_dereference(). - Updated geneve_fill_info() to use rtnl_dereference() for now. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260707145331.3717941-3-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysgeneve: pass geneve_config pointer to helper functionsEric Dumazet
In preparation for converting geneve->cfg to an RCU-protected pointer, update helper functions to explicitly accept a const struct geneve_config pointer instead of dereferencing geneve->cfg directly. Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/20260707145331.3717941-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysdrm/gpusvm: Zero HMM PFNs before scanning rangesStanislav Kinsburskii
drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table state without faulting missing entries by leaving default_flags set to zero. The HMM PFN array is still caller-owned input/output state, and the framework may preserve input bits while filling entries. It is not safe for the caller to hand HMM an uninitialized array and then treat entries without HMM_PFN_VALID as an authoritative unpopulated result. Use kvcalloc() for the temporary PFN array so entries that are not reported as valid start from the documented zero state. This prevents random stack or heap contents from being interpreted as HMM PFN flags or PFN values during the scan. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Cc: stable@vger.kernel.org Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/178406967042.1113483.2116704310277917086.stgit@skinsburskii
7 daysdrm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evictMatthew Brost
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com
7 daysnet/iucv: fix use-after-free of a severed iucv_pathBryam Vargas
af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued. Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets") Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1 Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260707-b4-disp-783fedbb-v1-1-463b9dbda2ea@proton.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysMerge branch ↵Paolo Abeni
'net-stmmac-eic7700-add-eth1-variant-support-and-update-delay-bindings' Zhi Li says: ==================== net: stmmac: eic7700: add eth1 variant support and update delay bindings This series updates Ethernet support for the ESWIN EIC7700 SoC, including support for the eth1 MAC variant. The series includes DT binding updates and stmmac glue driver updates for the EIC7700 Ethernet controller. The changes include: - Update the tx-internal-delay-ps binding property from a fixed enum list to a range-based definition, and make it optional with the corresponding driver update. - Add support for the EIC7700 eth1 MAC variant, which has silicon-specific RX sampling behavior and TX timing characteristics. A dedicated compatible string is introduced for this hardware variant, and the driver applies the required RX clock inversion handling and timing adjustments. Due to silicon characteristics, the eth1 interface has a fixed TX internal delay of approximately 2 ns and an RX sampling skew of 4-5 ns that cannot be compensated solely by standard RGMII delay settings. The binding models the effective TX delay range of this variant, while the driver handles the required hardware-specific timing configuration. Only the DT bindings and driver patches are included in this series. The DTS changes are intentionally omitted for the following reasons: - The HSP bus infrastructure is being introduced by Pinkesh Vaghela's DT series [0], currently under review. - The HSPCRG clock/reset series [1] provides additional infrastructure for the HSP subsystem. Once these dependencies are merged, a follow-up DT series will enable Ethernet, USB, eMMC, and SD across the HSP bus. Reference: [0] https://lore.kernel.org/lkml/20260706081055.1126275-1-pinkesh.vaghela@einfochips.com/ [1] https://lore.kernel.org/all/20260605060730.1605-1-dongxuyang@eswincomputing.com/ ==================== Link: https://patch.msgid.link/20260707064033.1265-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: stmmac: eic7700: add support for eth1 clock inversion variantZhi Li
The eth1 MAC exhibits silicon-inherent RX and TX timing behavior that differs from the eth0 implementation. At 1000Mbps, RX sampling requires clock inversion due to a fixed MAC input skew that cannot be compensated by standard RGMII delay settings. The TX path includes a fixed ~2ns internal delay introduced by the MAC silicon. This delay is always present and is already accounted for in the device tree tx-internal-delay-ps property as part of the effective output timing. The tx-internal-delay-ps property describes the effective delay seen at the MAC output. Since the hardware register controls only the programmable portion of the delay, the driver subtracts the fixed silicon-inherent component before programming the delay register. Use compatible-specific match data to identify the eth1 variant and apply RX clock inversion only at 1000Mbps. The PHY interface mode is adjusted via phy_fix_phy_mode_for_mac_delays() to avoid double-application of RGMII delays when MAC-side delays are already present. Link speed dependency means RX sampling configuration is applied in the fix_mac_speed callback after negotiation. No behavior changes for the existing eth0 controller. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064234.1333-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysnet: stmmac: eic7700: make RGMII delay properties optionalZhi Li
Make rx-internal-delay-ps and tx-internal-delay-ps optional in the EIC7700 DWMAC driver. The driver previously required both properties to be present and would fail probe when they were missing. This restricts valid hardware configurations where RGMII timing is instead provided by the PHY or board design. Update the driver to treat missing delay properties as zero delay, allowing systems without explicit MAC-side delay tuning to operate correctly. This aligns the driver behavior with the updated device tree binding and provides a safe default configuration when MAC-side delay programming is not required. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064218.1316-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-27 22:02:47 +0000