kernel/git/next/linux-next.git/net/devlink, branch master

Merge branch 'main' of https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

2026-09-07T12:26:14+00:00

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

devlink: use direct firmware requests for flash updates

2026-09-04T00:11:37+00:00

request_firmware() may enter the sysfs fallback and call try_to_freeze(). Devlink invokes it while holding the instance lock, causing syzbot to report: WARNING: syz-executor/... still has locks held! Firmware flash requests already name a file provided by userspace. Use request_firmware_direct() in both flash update paths so a missing file fails immediately instead of entering the sysfs fallback. This keeps the normal devlink locking intact. On systems with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y, devlink flash can no longer obtain a missing image through that fallback. Callers still receive the existing error result, and netlink users retain the extack message. Cc: stable+noautosel@kernel.org # FW_LOADER_USER_HELPER_FALLBACK=y has no known use Reported-by: syzbot+372a7d84708b07f64d9b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=372a7d84708b07f64d9b Suggested-by: Jakub Kicinski Signed-off-by: Miguel Garcia Link: https://patch.msgid.link/20260902095739.3587287-1-miguelgarciaroman8@gmail.com Signed-off-by: Jakub Kicinski

devlink: add generic device max_sfs parameter

2026-08-12T01:06:30+00:00

Add a new generic devlink device parameter (max_sfs) to control if and how many light-weight NIC subfunctions can be created. Subfunctions are a light-weight network functions backed by an underlying PCI function. Their lifecycle can already be managed by devlink, but currently users cannot enable them in the device. They can be enabled/disabled only via external vendor tools. This parameter allows subfunctions to be enabled (>0) or disabled (0) via devlink. A subsequent patch will add support for max_sfs to the mlx5 driver. Signed-off-by: Nikolay Aleksandrov Reviewed-by: David Ahern Reviewed-by: Jiri Pirko Reviewed-by: Aleksandr Loktionov Reviewed-by: Alexander Lobakin Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260806073037.3001886-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-08-06T18:53:47+00:00

Cross-merge networking fixes after downstream PR (net-7.2-rc7). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski

devlink: Expose external flag for PCI SF ports

2026-08-05T23:39:54+00:00

The external flag is part of the PCI SF port attributes, but unlike the PCI PF and PCI VF flavours it was never filled into the port dump, so userspace could not query it directly. Reporting of the external flag was missed for SF ports. Hence, put DEVLINK_ATTR_PORT_EXTERNAL for the PCI SF flavour as well, matching what PCI PF and PCI VF ports already report. $ devlink port show pci/0033:01:00.0/163840 pci/0033:01:00.0/163840: type eth netdev eth1 flavour pcisf controller 1 pfnum 0 sfnum 77 external true splittable false Reviewed-by: Parav Pandit Signed-off-by: Shay Drory Link: https://patch.msgid.link/20260803090012.257242-1-shayd@nvidia.com Signed-off-by: Jakub Kicinski

devlink: fix net namespace reference leak in reload

2026-08-01T01:23:44+00:00

devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path. Fixes: 2edd92570441 ("devlink: don't allow to change net namespace for FW_ACTIVATE reload action") Signed-off-by: Or Har-Toov Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Reviewed-by: Antoine Tenart Link: https://patch.msgid.link/20260729080600.2427721-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

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

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: Allow parent dev for rate-set and rate-new

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

Currently, a devlink rate's parent device is assumed to be the same as the one where the devlink rate is created. This patch changes that to allow rate commands to accept an additional argument that specifies the parent dev. This will allow devlink rate groups with leafs from other devices. Example of the new usage with ynl: Creating a group on pci/0000:08:00.1 with a parent to an already existing pci/0000:08:00.1/group1: ./tools/net/ynl/pyynl/cli.py --spec \ Documentation/netlink/specs/devlink.yaml --do rate-new --json '{ "bus-name": "pci", "dev-name": "0000:08:00.1", "rate-node-name": "group2", "rate-parent-node-name": "group1", "parent-dev": { "bus-name": "pci", "dev-name": "0000:08:00.1" } }' Setting the parent of leaf node pci/0000:08:00.1/65537 to pci/0000:08:00.0/group1: ./tools/net/ynl/pyynl/cli.py --spec \ Documentation/netlink/specs/devlink.yaml --do rate-set --json '{ "bus-name": "pci", "dev-name": "0000:08:00.1", "port-index": 65537, "parent-dev": { "bus-name": "pci", "dev-name": "0000:08:00.0" }, "rate-parent-node-name": "group1" }' 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-7-tariqt@nvidia.com Signed-off-by: Paolo Abeni