kernel/git/next/linux-next.git/Documentation/networking, branch master

devlink: print controller prefix for non-zero controller

2026-07-08T09:23:49+00:00

The controller prefix (c) in phys_port_name is currently restricted to external host controllers. This layout sufficed when DPUs only had a single local controller and one or more external host controllers. However, newer devices can have multiple controllers within the DPU itself, even within a single host environment. To support these topologies, allow drivers to report the controller number regardless of the "external" flag status. Any non-zero controller number will now be explicitly reported, even for single-host or local DPU controllers. Existing ports with controller=0 are unaffected. Update documentation and kdoc to clarify that a non-zero controller number does not require the external flag to be set. Signed-off-by: Moshe Shemesh Reviewed-by: Parav Pandit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260702111726.816985-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni

net: document NETDEV_UNREGISTER unlocked rationale

2026-07-07T13:31:37+00:00

The lock-state table marks UNREGISTER as unlocked without saying why. Add a short note that many handlers release the lowers via dev_close(). Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260702224150.3730033-7-sdf@fomichev.me Signed-off-by: Paolo Abeni

net: require instance lock for NETDEV_DOWN/GOING_DOWN notifiers

2026-07-07T13:31:37+00:00

Sprinkle a few asserts about ops lock: netif_close_many and __dev_notify_flags should now consistently run under the lock Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260702224150.3730033-6-sdf@fomichev.me Signed-off-by: Paolo Abeni

net/mlx5: Document devlink rates

2026-07-07T09:31:27+00:00

It seems rates were not documented in the mlx5-specific file, so add examples on how to limit VFs and groups and also provide an example of the intended way to achieve cross-esw scheduling. Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-15-tariqt@nvidia.com Signed-off-by: Paolo Abeni

devlink: Allow rate node parents from other devlinks

2026-07-07T09:31:26+00:00

This commit makes use of the building blocks previously added to implement cross-device rate nodes. A new 'supported_cross_device_rate_nodes' bool is added to devlink_ops which lets drivers advertise support for cross-device rate objects. If enabled and if there is a common shared devlink instance, then: - all rate objects will be stored in the top-most common nested instance and - rate objects can have parents from other devices sharing the same common instance. Storing rates in the common shared ancestor is safe, because it is reference counted by its nested devlink instances, so it's guaranteed to outlive them. Furthermore, the shared devlink infra guarantees a given nested devlink hierarchy is managed by the same driver. The parent devlink from info->ctx is not locked, so none of its mutable fields can be used. But parent setting only requires comparing devlink pointer comparisons. Additionally, since the shared devlink is locked, other rate operations cannot concurrently happen. Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-8-tariqt@nvidia.com Signed-off-by: Paolo Abeni

devlink: Update nested instance locking comment

2026-07-07T09:31:26+00:00

In commit [1] a comment about nested instance locking was updated. But there's another place where this is mentioned, so update that as well. [1] commit 0061b5199d7c ("devlink: Reverse locking order for nested instances") Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni

ipv4: fib: Define fib_table_hash_lock under CONFIG_IP_MULTIPLE_TABLES.

2026-07-07T08:51:06+00:00

When CONFIG_IP_MULTIPLE_TABLES is disabled, fib_new_table() is fib_get_table(), and no new table is created. Let's move net->ipv4.fib_table_hash_lock under CONFIG_IP_MULTIPLE_TABLES. While at it, netns_ipv4_sysctl.rst is updated. Suggested-by: Ido Schimmel Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260702044437.591864-2-kuniyu@google.com Signed-off-by: Paolo Abeni

vlan: defer real device state propagation to netdev_work

2026-06-25T17:18:40+00:00

vlan_device_event() generates nested UP/DOWN, MTU and feature change events. It executes an event for the VLAN device directly from the notifier - while the locks of the lower device are held. This causes deadlocks, for example: bond (3) bond_update_speed_duplex(vlan) | ^ v vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings() | ^ v dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings() The dummy device is ops locked, vlan creates a nested event (2), then bond wants to ask vlan for link state (3). bond uses the "I'm already holding the instance lock" flavor of API. But in this case the lock held refers to vlan itself. We hit vlan's link settings trampoline (4) and call __ethtool_get_link_ksettings() which tries to lock dummy. Deadlock. There's no clean way for us to tell the vlan_ethtool_get_link_ksettings() that the caller is already in lower device's critical section. Defer the propagation to the per-netdev work facility instead: the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*), and ndo_work (vlan_dev_work) applies the change later. Hopefully nobody expects the VLAN state changes to be instantaneous. If someone does expect the changes to be instantaneous we will have to do the same thing Stan did for rx_mode and "strategically" place sync calls, to make sure such delayed works are executed after we drop the ops lock but before we drop rtnl_lock. Stan suggests that if we need that down the line we may consider reshaping the mechanism into "async notifications". AFAICT only vlan does this sort of netdev open chaining, so as a first try I think that sticking the complexity into the vlan code makes sense. One corner case is that we need to cancel the event if user explicitly changes the state before work could run. Consider the following operations with vlan0 on top of dummy0: ip link set dev dummy0 up # queues work to up vlan0 ip link set dev vlan0 down # user explicitly downs the vlan ndo_work # acts on the stale event Reported-by: syzbot+09da62a8b78959ceb8bb@syzkaller.appspotmail.com Reported-by: syzbot+cb67c392b0b8f0fd0fc1@syzkaller.appspotmail.com Reported-by: syzbot+9bb8bd77f3966641f298@syzkaller.appspotmail.com Fixes: 9f275c2e9020 ("net: ethtool: make sure __ethtool_get_link_ksettings() is ops-locked") Reviewed-by: Kuniyuki Iwashima Reviewed-by: Nicolai Buchwitz Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260624182018.2445732-4-kuba@kernel.org Signed-off-by: Jakub Kicinski

appletalk: stop storing per-interface state in struct net_device

2026-06-16T21:37:06+00:00

AppleTalk keeps its per-interface control block (struct atalk_iface) directly in struct netdevice (dev->atalk_ptr). This is the only thing tying the protocol into the core net_device layout and is the sole blocker to moving AppleTalk out of tree. Replace dev->atalk_ptr with a small ifindex-keyed hashtable internal to ddp.c. The existing atalk_interfaces list stays the owner of the iface objects; the hashtable is purely a fast dev->iface index and reuses the same atalk_interfaces_lock. AFAICT this patch does not make this code any more racy than it already is, I'm sure Sashiko will point out some basically existing bugs. AFAICT atalk_interfaces_lock is the innermost lock already. Acked-by: Stephen Hemminger Link: https://patch.msgid.link/20260615222935.947233-2-kuba@kernel.org Signed-off-by: Jakub Kicinski

tcp: rehash onto different local ECMP path on retransmit timeout

2026-06-15T22:57:31+00:00

Currently sk_rethink_txhash() re-rolls the socket's txhash on RTO, PLB, and spurious-retransmission events, but the cached route is reused and the new hash is not propagated into the ECMP path selection logic. Two changes are needed to make rehash select a different local ECMP path: 1. Add __sk_dst_reset() alongside sk_rethink_txhash() in tcp_write_timeout(), tcp_rcv_spurious_retrans(), and tcp_plb_check_rehash() so the cached dst is invalidated and the next transmit triggers a fresh route lookup. 2. Set fl6->mp_hash from sk_txhash (or tcp_rsk(req)->txhash for SYN/ACK retransmits and syncookies) in tcp_v6_connect(), inet6_sk_rebuild_header(), inet6_csk_route_req(), inet6_csk_route_socket(), tcp_v6_send_response(), and cookie_v6_check() so fib6_select_path() picks a path based on the new hash. The mp_hash override only applies to fib_multipath_hash_policy 0 (the default L3 policy). Its hash includes the flow label, but that is 0 by default -- np->flow_label is unset, and auto_flowlabels only computes the on-wire label later, per packet -- so flows to the same peer share one local path. Keying the hash on sk_txhash makes the local path per-connection and lets a rehash re-select it. Policies 1-3 are left unchanged. The mp_hash assignment is factored into a small helper, ip6_ecmp_set_mp_hash(), shared by inet6_csk_route_req(), inet6_csk_route_socket(), tcp_v6_connect(), inet6_sk_rebuild_header(), tcp_v6_send_response(), and cookie_v6_check(). It applies (txhash >> 1) ?: 1 for policy 0 (the >> 1 keeps mp_hash in the 31-bit range; ?: 1 keeps it non-zero, since 0 would fall back to rt6_multipath_hash()). inet6_csk_route_socket() calls it only for sk_protocol == IPPROTO_TCP so that non-TCP callers (e.g., L2TP via inet6_csk_xmit) fall through to rt6_multipath_hash() and retain their existing flow-key-based ECMP behavior. tcp_v6_send_response() also sets mp_hash from the response txhash so that a control packet (a RST from the full socket, or an ACK from a time-wait socket) selects the same local ECMP nexthop as the connection's txhash rather than falling back to the flow hash. The time-wait socket's tw_txhash is copied from sk_txhash when the connection enters TIME_WAIT, so it reflects any rehash that occurred. Setting mp_hash explicitly is necessary because the default ECMP hash derives from fl6->flowlabel via np->flow_label, which is not updated from sk_txhash (REPFLOW is off by default). ip6_make_flowlabel() cannot help either, as it runs after the route lookup. As a consequence, for policy 0 the local ECMP path of an IPv6 TCP flow follows sk_txhash even when fl6->flowlabel is non-zero, e.g. a reflected (REPFLOW) or explicitly set (IPV6_FLOWLABEL_MGR) flow label. This is intentional: only local path selection changes, so rehash can recover from a failed path; the on-wire flow label is unchanged. sk_set_txhash() is moved before ip6_dst_lookup_flow() in tcp_v6_connect() so the initial ECMP path is selected by the same txhash that subsequent route rebuilds will use. This avoids unintended path changes when the cached dst is naturally invalidated (e.g., by PMTU discovery or route changes). The rehash sites (tcp_write_timeout(), tcp_plb_check_rehash(), and tcp_rcv_spurious_retrans()) call __sk_rethink_txhash_reset_dst(), which re-rolls the txhash and, when it changed, drops the cached dst so the next transmit re-runs route selection. The dst reset is guarded by sk->sk_family == AF_INET6 since IPv4 ECMP does not currently use sk_txhash for path selection. For IPv4-mapped IPv6 sockets this produces a redundant dst reset on a cold path (RTO/PLB); the subsequent IPv4 route lookup returns the same result. The helper is deliberately separate from sk_rethink_txhash() itself: dst_negative_advice() calls sk_rethink_txhash() before its own dst op, so resetting the dst inside sk_rethink_txhash() would skip that op (e.g. rt6_remove_exception_rt()). For syncookies, cookie_init_sequence() computes the cookie value before route_req() and sets txhash so the SYN-ACK selects the same ECMP path that cookie_v6_check() will use when the full socket is created. cookie_tcp_reqsk_init() derives txhash from the cookie so the full socket's ECMP path matches the SYN-ACK. Both the SYN-ACK assignment in tcp_conn_request() and the full-socket assignment in cookie_tcp_reqsk_init() set txhash from the cookie for IPv4 and IPv6 alike. On IPv6 this drives ECMP path selection; on IPv4, which does not use sk_txhash for ECMP, it only affects TX-queue selection. That selection scales the hash by its high bits (reciprocal_scale()), which are uniform in the keyed secure_tcp_syn_cookie() output -- the MSS index only perturbs the low bits -- so the queue distribution matches net_tx_rndhash(). cookie_init_sequence() is split from the former version that also called tcp_synq_overflow() and incremented SYNCOOKIESSENT; those side effects are now in cookie_record_sent(), called after route_req() succeeds so they are not bumped when route_req() fails. cookie_record_sent() is guarded by CONFIG_SYN_COOKIES to match the guard on tcp_synq_overflow(). route_req() receives 0 as tw_isn for the syncookie path so that tcp_v6_init_req() still saves ireq->pktopts for REPFLOW flowlabel reflection and IPv6 cmsg options. The ecn_ok clear for syncookies without timestamps stays after tcp_ecn_create_request() so it takes precedence. Signed-off-by: Neil Spring Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260615042158.1600746-2-ntspring@meta.com Signed-off-by: Jakub Kicinski