* Re: [PATCH net-next] net: phy: aquantia: use ADVERTISE_XNP for extended next page advertising
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew, kuba, davem, edumazet, pabeni, horms, linux, hkallweit1,
vladimir.oltean, camelia.groza, thomas.petazzoni, netdev,
linux-kernel
In-Reply-To: <20260428125827.238469-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 14:58:27 +0200 you wrote:
> When configuring the link parameters in forced mode for the AQR-105, the
> Extended Next Page bit gets advertised for Multi-Gigabit modes.
>
> This is done through bit 12 of MDIO_AN_ADVERTISE in MDIO_MMD_AN. This
> contains a copy of the MII_ADVERTISE, for which 802.3 defines bit 12 as
> the Extended Next Page advertising. This bit used to be marked as
> reserved, but a proper define for it was added in :
>
> [...]
Here is the summary with links:
- [net-next] net: phy: aquantia: use ADVERTISE_XNP for extended next page advertising
https://git.kernel.org/netdev/net-next/c/e2d217fe3ff2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] selftests: drv-net: rss: add case for field config on RSS context
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
dimitri.daskalakis1, pavan.chebbi, linux-kselftest
In-Reply-To: <20260428203624.1224387-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 13:36:24 -0700 you wrote:
> We had some issues with a suspected traffic imbalance on an RSS
> context. Make sure the tests cover the RXFH field selection
> vs additional contexts.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: shuah@kernel.org
> CC: dimitri.daskalakis1@gmail.com
> CC: pavan.chebbi@broadcom.com
> CC: linux-kselftest@vger.kernel.org
>
> [...]
Here is the summary with links:
- [net-next] selftests: drv-net: rss: add case for field config on RSS context
https://git.kernel.org/netdev/net-next/c/1656f1788342
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 net-next] net/sched: rename qstats_overlimit_inc() to qstats_cpu_overlimit_inc()
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260428070919.3109557-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 07:09:19 +0000 you wrote:
> qstats_overlimit_inc() is only used to increment per cpu overlimits.
>
> It can use this_cpu_inc() to avoid this_cpu_ptr() extra cost
> and avoid potential store tearing.
>
> Change qstats_overlimit_inc() name and its argument type.
>
> [...]
Here is the summary with links:
- [v4,net-next] net/sched: rename qstats_overlimit_inc() to qstats_cpu_overlimit_inc()
https://git.kernel.org/netdev/net-next/c/52472519ef61
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 11/11] ice: add dpll peer notification for paired SMA and U.FL pins
From: Jakub Kicinski @ 2026-04-30 0:41 UTC (permalink / raw)
To: Jacob Keller
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Aleksandr Loktionov, Simon Horman,
Jiri Pirko, netdev, Petr Oros, Alexander Nowlin,
Arkadiusz Kubalewski
In-Reply-To: <3c1f1894-e969-4dc2-914f-9e15db35dab5@intel.com>
On Wed, 29 Apr 2026 16:28:48 -0700 Jacob Keller wrote:
> Either way, to my eyes this looks like a pre-existing issue that may
> need some attention but I don't feel like it should block these fixes.
Yes, I think "fail to notify" is / should be handled by setting
an error on all listener sockets. It's very much not the job
for this series.
Looks like the series did not get ingested by Sashiko fully,
I kicked off another run locally, so probably won't get to
apply this today.
I don't have any "organic" comments :)
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5: Add MLX5_VXLAN config option
From: Marc Harvey @ 2026-04-30 0:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni, netdev,
linux-rdma, linux-kernel, Kuniyuki Iwashima
In-Reply-To: <20260428184631.40f1f1b7@kernel.org>
On Tue, Apr 28, 2026 at 6:46 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 28 Apr 2026 22:44:34 +0000 Marc Harvey wrote:
> > Currently, there is no way to disable mlx5 vxlan offloading if vxlan
> > is enabled. We've (possibly) seen some minor udp rr and udp stream
> > regressions when enabling vxlan, and want a way to disable this
> > offloading. Also coupling vxlan offloading with vxlan enablement
> > generally limits the flexability of vxlan setups.
> >
> > Add a new config option for mlx5 vxlan offloading specifically, so
> > that users can use vxlan without automatically opting in to the
> > offloading.
> >
> > To keep the same behavior as before, the new config option is enabled
> > by default if vxlan is enabled.
>
> Can we delay init of whatever makes the device slow down until the
> first vxlan port is registered? A kconfig level optimization of this
> sort will have rather limited applicability.
There would still be the problem of wanting to use vxlan without vxlan
offload. Agree that a kconfig might not be ideal, but it is currently
guarded by a kconfig that offers no choice to opt out.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: sit: remove redundant ret = 0 assignment
From: kernel test robot @ 2026-04-30 0:49 UTC (permalink / raw)
To: Yue Haibing, davem, dsahern, edumazet, kuba, pabeni, horms
Cc: llvm, oe-kbuild-all, netdev, linux-kernel
In-Reply-To: <20260403084402.4105936-1-yuehaibing@huawei.com>
Hi Yue,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Yue-Haibing/ipv6-sit-remove-redundant-ret-0-assignment/20260425-024700
base: net-next/main
patch link: https://lore.kernel.org/r/20260403084402.4105936-1-yuehaibing%40huawei.com
patch subject: [PATCH net-next] ipv6: sit: remove redundant ret = 0 assignment
config: loongarch-defconfig (https://download.01.org/0day-ci/archive/20260430/202604300826.7OKegoUR-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260430/202604300826.7OKegoUR-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604300826.7OKegoUR-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> net/ipv6/sit.c:362:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
362 | if ((len && copy_to_user(a + 1, kp, len)) || put_user(len, &a->datalen))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/ipv6/sit.c:367:9: note: uninitialized use occurs here
367 | return ret;
| ^~~
net/ipv6/sit.c:362:2: note: remove the 'if' if its condition is always true
362 | if ((len && copy_to_user(a + 1, kp, len)) || put_user(len, &a->datalen))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
363 | ret = -EFAULT;
net/ipv6/sit.c:312:9: note: initialize the variable 'ret' to silence this warning
312 | int ret;
| ^
| = 0
1 warning generated.
vim +362 net/ipv6/sit.c
fadf6bf0606913 Templin, Fred L 2008-03-11 305
3e7a1c7c561ed8 Arnd Bergmann 2021-07-27 306 static int ipip6_tunnel_get_prl(struct net_device *dev, struct ip_tunnel_prl __user *a)
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 307 {
fd5d687b76b325 Christoph Hellwig 2020-05-19 308 struct ip_tunnel *t = netdev_priv(dev);
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 309 struct ip_tunnel_prl kprl, *kp;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 310 struct ip_tunnel_prl_entry *prl;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 311 unsigned int cmax, c = 0, ca, len;
3c6132ccc58e8a Yue Haibing 2026-04-08 312 int ret;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 313
fd5d687b76b325 Christoph Hellwig 2020-05-19 314 if (dev == dev_to_sit_net(dev)->fb_tunnel_dev)
fd5d687b76b325 Christoph Hellwig 2020-05-19 315 return -EINVAL;
fd5d687b76b325 Christoph Hellwig 2020-05-19 316
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 317 if (copy_from_user(&kprl, a, sizeof(kprl)))
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 318 return -EFAULT;
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 319 cmax = kprl.datalen / sizeof(kprl);
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 320 if (cmax > 1 && kprl.addr != htonl(INADDR_ANY))
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 321 cmax = 1;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 322
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 323 /* For simple GET or for root users,
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 324 * we try harder to allocate.
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 325 */
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 326 kp = (cmax <= 1 || capable(CAP_NET_ADMIN)) ?
69050f8d6d075d Kees Cook 2026-02-20 327 kzalloc_objs(*kp, cmax, GFP_KERNEL_ACCOUNT | __GFP_NOWARN) :
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 328 NULL;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 329
284fda1eff8a8b kernel test robot 2021-03-27 330 ca = min(t->prl_count, cmax);
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 331
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 332 if (!kp) {
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 333 /* We don't try hard to allocate much memory for
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 334 * non-root users.
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 335 * For root users, retry allocating enough memory for
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 336 * the answer.
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 337 */
69050f8d6d075d Kees Cook 2026-02-20 338 kp = kzalloc_objs(*kp, ca,
69050f8d6d075d Kees Cook 2026-02-20 339 GFP_ATOMIC | __GFP_ACCOUNT | __GFP_NOWARN);
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 340 if (!kp) {
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 341 ret = -ENOMEM;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 342 goto out;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 343 }
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 344 }
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 345
adabdd8f6acabc katrinzhou 2022-06-28 346 rcu_read_lock();
ef9a9d1183b36f Eric Dumazet 2009-10-23 347 for_each_prl_rcu(t->prl) {
298bf12ddb2584 Sascha Hlusiak 2009-09-29 348 if (c >= cmax)
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 349 break;
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 350 if (kprl.addr != htonl(INADDR_ANY) && prl->addr != kprl.addr)
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 351 continue;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 352 kp[c].addr = prl->addr;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 353 kp[c].flags = prl->flags;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 354 c++;
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 355 if (kprl.addr != htonl(INADDR_ANY))
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 356 break;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 357 }
adabdd8f6acabc katrinzhou 2022-06-28 358
ef9a9d1183b36f Eric Dumazet 2009-10-23 359 rcu_read_unlock();
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 360
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 361 len = sizeof(*kp) * c;
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 @362 if ((len && copy_to_user(a + 1, kp, len)) || put_user(len, &a->datalen))
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 363 ret = -EFAULT;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 364
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 365 kfree(kp);
adabdd8f6acabc katrinzhou 2022-06-28 366 out:
2b4743bd6be9fe YOSHIFUJI Hideaki 2008-06-16 367 return ret;
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 368 }
300aaeeaab5f44 YOSHIFUJI Hideaki 2008-03-24 369
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] hv_sock: fix ARM64 support
From: patchwork-bot+netdevbpf @ 2026-04-30 0:50 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: netdev, kys, haiyangz, wei.liu, decui, longli, sgarzare, davem,
edumazet, kuba, pabeni, horms, mhklinux, himadrispandya,
linux-hyperv, virtualization, linux-kernel
In-Reply-To: <20260428125339.13963-1-hamzamahfooz@linux.microsoft.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 08:53:39 -0400 you wrote:
> VMBUS ring buffers must be page aligned. Therefore, the current value of
> 24K presents a challenge on ARM64 kernels (with 64K pages). So, use
> VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
> hold all of the relevant data.
>
> Cc: stable@vger.kernel.org
> Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
> Tested-by: Dexuan Cui <decui@microsoft.com>
> Reviewed-by: Dexuan Cui <decui@microsoft.com>
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
>
> [...]
Here is the summary with links:
- hv_sock: fix ARM64 support
https://git.kernel.org/netdev/net/c/b31681206e3f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Jakub Kicinski @ 2026-04-30 0:54 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: netdev, stable, Yibo Dong, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, MD Danish Anwar, Vadim Fedorenko
In-Reply-To: <20260428030826.47509-1-enelsonmoore@gmail.com>
On Mon, 27 Apr 2026 20:08:25 -0700 Ethan Nelson-Moore wrote:
> The rnpgbe driver as currently shipped in the kernel is incomplete and
> has no useful functionality. It will bind to a PCI device and create a
> network device, but that device does not function (its .ndo_start_xmit
> callback, rnpgbe_xmit_frame, just drops all packets). This situation
> means that users could enable this driver and have it load and attach
> to their device but not transfer any data. To remove the potential for
> user confusion, mark the driver as broken until it is completed and
> explain why this was done.
I'm having second thoughts about this. I'm worried users will come to
expect that drivers are marked as BROKEN until such time that they
can be considered a sufficiently complete replacement for an OOT /
vendor driver. This will be highly subjective.
^ permalink raw reply
* Re: [PATCH v2 net] net: enetc: fix VSI mailbox timeout handling and DMA lifecycle
From: Jakub Kicinski @ 2026-04-30 0:59 UTC (permalink / raw)
To: wei.fang
Cc: Jakub Kicinski, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, pabeni, netdev, linux-kernel, imx
In-Reply-To: <20260428063111.2869408-1-wei.fang@nxp.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: enetc: fix VSI mailbox timeout handling and DMA lifecycle
This patch preserves the VSI mailbox DMA buffer in si->msg so it can
be freed on the next send (once the mailbox is no longer busy), and
adds a final free in enetc_vf_remove(). It also bails out early if
the mailbox is still busy when a new message is submitted.
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> index 6c4b374bcb0e..e8c5adee9743 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
[ ... ]
> @@ -258,6 +281,7 @@ static int enetc_vf_probe(struct pci_dev *pdev,
> static void enetc_vf_remove(struct pci_dev *pdev)
> {
> struct enetc_si *si = pci_get_drvdata(pdev);
> + struct enetc_msg_swbd msg = si->msg;
> struct enetc_ndev_priv *priv;
>
> priv = netdev_priv(si->ndev);
> unregister_netdev(si->ndev);
Is there a race between this local copy of si->msg and a concurrent
ndo callback?
The local 'msg' is captured at function entry, before unregister_netdev()
has run, and .remove() does not hold RTNL. During that window, userspace
(for example 'ip link set dev ethX address ...') can acquire RTNL and
invoke enetc_vf_set_mac_addr() -> enetc_msg_vsi_set_primary_mac_addr()
-> enetc_msg_vsi_send() on the same si.
Inside enetc_msg_vsi_send(), on the non-busy path:
/* Free the DMA buffer of the last message */
enetc_msg_dma_free(dev, &si->msg);
si->msg = *msg;
the buffer whose (vaddr, dma, size) our local 'msg' still holds a copy
of gets freed, and si->msg is replaced with a new allocation.
>
> enetc_free_msix(priv);
>
> enetc_free_si_resources(priv);
> enetc_teardown_cbdr(&si->cbd_ring);
>
> free_netdev(si->ndev);
>
> enetc_pci_remove(pdev);
> + enetc_msg_dma_free(&pdev->dev, &msg);
> }
When this trailing enetc_msg_dma_free(&pdev->dev, &msg) runs, can it
call dma_free_coherent() on a buffer that enetc_msg_vsi_send() already
freed, and also leak the newer buffer now sitting in si->msg (which is
no longer referenced by anything)?
Would capturing msg = si->msg after unregister_netdev() returns (i.e.
once no further ndo callbacks can race) avoid both the double free
and the leak?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next V2 0/3] net/mlx5: Fix E-Switch work queue deadlock with devlink lock
From: patchwork-bot+netdevbpf @ 2026-04-30 1:00 UTC (permalink / raw)
To: Tariq Toukan
Cc: edumazet, kuba, pabeni, andrew+netdev, davem, saeedm, leon,
mbloch, netdev, linux-rdma, linux-kernel, gal, dtatulea
In-Reply-To: <20260428051018.219093-1-tariqt@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 08:10:14 +0300 you wrote:
> Hi,
>
> See detailed description by Mark below [1].
>
> Regards,
> Tariq
>
> [...]
Here is the summary with links:
- [net-next,V2,1/3] net/mlx5: E-Switch, move work queue generation counter
https://git.kernel.org/netdev/net-next/c/f950ddb57ce4
- [net-next,V2,2/3] net/mlx5: E-Switch, introduce generic work queue dispatch helper
https://git.kernel.org/netdev/net-next/c/2a110ee54e89
- [net-next,V2,3/3] net/mlx5: E-Switch, fix deadlock between devlink lock and esw->wq
https://git.kernel.org/netdev/net-next/c/6a92fe1956d2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] r8152: Use ocp/mdio test and clear functions in r8157_hw_phy_cfg()
From: patchwork-bot+netdevbpf @ 2026-04-30 1:00 UTC (permalink / raw)
To: Birger Koblitz
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-usb, netdev,
linux-kernel, hsu.chih.kai
In-Reply-To: <20260428-use_bit_functions-v1-1-6eb5a3507610@birger-koblitz.de>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 05:44:58 +0200 you wrote:
> Replace explicit testing of bits and clearing these bits by existing
> functions ocp_word_test_and_clr_bits() and r8152_mdio_test_and_clr_bit()
> to re-use this code.
>
> This allows to remove the "ocp_data" variable. Also remove the "ret" variable
> which was incorrectly used for the r8153_phy_status() return value which
> is a u16, so that the remaining "data" variable is sufficient.
>
> [...]
Here is the summary with links:
- [net-next] r8152: Use ocp/mdio test and clear functions in r8157_hw_phy_cfg()
https://git.kernel.org/netdev/net-next/c/b7ebbf9f7aea
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] r8152: Fix double consecutive clearing of PLA_MCU_SPDWN_EN bit
From: patchwork-bot+netdevbpf @ 2026-04-30 1:00 UTC (permalink / raw)
To: Birger Koblitz
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-usb, netdev,
linux-kernel, hsu.chih.kai
In-Reply-To: <20260428-patch_double-v1-1-27c830a9eb2e@birger-koblitz.de>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 05:43:38 +0200 you wrote:
> Due to a Copy & Paste Error, the PLA_MCU_SPDWN_EN bit was cleared
> twice consecutively using ocp_word_clr_bits. Fix that.
>
> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
> ---
> This fixes the issue raised in
> https://lore.kernel.org/netdev/8b324f8c-f4f8-4e90-b5d6-9b87ec3daf2b@redhat.com/
> that due to an editing error, PLA_MCU_SPDWN_EN is cleared twice
> consecutively.
>
> [...]
Here is the summary with links:
- [net-next] r8152: Fix double consecutive clearing of PLA_MCU_SPDWN_EN bit
https://git.kernel.org/netdev/net-next/c/115553b80f77
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Rename get_src_port_id callback in get_sport
From: patchwork-bot+netdevbpf @ 2026-04-30 1:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260428-airoha-get_src_port_id-callback-v1-1-3f765c91c1e8@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 07:23:38 +0200 you wrote:
> For code consistency, rename get_src_port_id callback in get_sport.
> Please note this patch does not introduce any logical change and it is
> just a cosmetic patch.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 10 +++++-----
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> [...]
Here is the summary with links:
- [net-next] net: airoha: Rename get_src_port_id callback in get_sport
https://git.kernel.org/netdev/net-next/c/c06a2f2903f6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH RESEND net-next] net/sun: Fix multiple typos in comments
From: Jakub Kicinski @ 2026-04-30 1:03 UTC (permalink / raw)
To: j.raczynski; +Cc: Jakub Kicinski, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20260428101728.3537456-1-j.raczynski@samsung.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/sun: Fix multiple typos in comments
This patch fixes various typos in comments across the sun ethernet
drivers. A couple of the replacements may warrant a second look.
> diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
> index fe00e7dd3fe4..74fb0de12d21 100644
> --- a/drivers/net/ethernet/sun/cassini.c
> +++ b/drivers/net/ethernet/sun/cassini.c
[ ... ]
> @@ -4547,7 +4547,7 @@ static int cas_get_link_ksettings(struct net_device *dev,
> }
> if (linkstate != link_up) {
> /* Force these to "unknown" if the link is not up and
> - * autonogotiation in enabled. We can set the link
> + * autonegotiation in enabled. We can set the link
The "autonogotiation" to "autonegotiation" change looks correct, but
the neighbouring "in enabled" in the same sentence appears to be a
leftover grammar slip (should it read "is enabled"?). Since this
sentence is already being touched as part of the typo cleanup, would
it make sense to fix that at the same time?
> * speed to 0, but not cmd->duplex,
> * because its legal values are 0 and 1. Ethtool will
> * print the value reported in parentheses after the
[ ... ]
> diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c
> index 4c9d5d4dd8a0..efbf042e9352 100644
> --- a/drivers/net/ethernet/sun/sunhme.c
> +++ b/drivers/net/ethernet/sun/sunhme.c
> @@ -1118,7 +1118,7 @@ static void happy_meal_transceiver_check(struct happy_meal *hp, void __iomem *tr
> *
> * We use skb_reserve() to align the data block we get in the skb. We
> * also program the etxregs->cfg register to use an offset of 2. This
> - * imperical constant plus the ethernet header size will always leave
> + * emperical constant plus the ethernet header size will always leave
Neither "imperical" nor "emperical" is a correct English word; the
intended word is "empirical". Was the replacement here meant to be
"empirical"?
> * us with a nicely aligned ip header once we pass things up to the
> * protocol layers.
> *
--
pw-bot: cr
^ permalink raw reply
* [PATCH v2 net-next 0/8] ptp: Add PHC timestamp quality attributes
From: Arthur Kiyanovski @ 2026-04-30 1:10 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, Woodhouse, David, Sarna, Yonatan,
Machulsky, Zorik, Matushevsky, Alexander, Saeed Bshara,
Wilson, Matt, Liguori, Anthony, Bshara, Nafea, Schmeilin, Evgeny,
Belgazal, Netanel, Saidi, Ali, Herrenschmidt, Benjamin,
Dagan, Noam, Arinzon, David, Ostrovsky, Evgeny, Tabachnik, Ofir,
Bernstein, Amit
This series adds quality attributes to PTP Hardware Clock (PHC)
timestamps, allowing userspace to obtain error bound, clock status,
timescale, and raw counter values alongside timestamps in a single
call.
Motivation
----------
The existing PTP APIs return timestamps without any indication of
their quality. Applications that need clock accuracy and
synchronization status commonly rely on external tools such as
ptp4l, which implement synchronization logic and can export their
measurement of clock accuracy. For managed PHC devices — such as
the ENA network adapter, whose clock is synchronized by the device
without userspace involvement — these tools are not available, and
the existing APIs lack a way to report quality metrics to consumers
of time.
This was previously proposed as an RFC [1] with a single ioctl.
Based on community feedback, the design was reworked to cover both
the extended (multi-sample) and precise (cross-timestamp) paths,
with a shared attributes structure.
Design
------
This series introduces two new ioctls that extend the existing
extended and precise timestamp paths with per-timestamp quality
attributes: error bound (nanoseconds), clock synchronization
status, timescale, and raw hardware counter values.
A capability flag is added to ptp_clock_caps so userspace can
discover attributes support.
Patches 2-3 add testptp support for the new ioctls.
Patch 4 implements the attributes for ptp_vmclock, reporting
error bound, clock status, timescale, and raw counter values.
Patches 5-8 implement the attributes for the ENA driver,
reporting error bound from the device's PHC layer.
v2:
- Fix build bisectability: move ena_com.c consumer updates into
patch 6/8 and ena_phc.c caller update into patch 7/8 so each
patch compiles independently.
- Add missing Cc for Amit Bernstein (co-author of ENA patches).
[1] https://lore.kernel.org/netdev/20250724115657.150-1-darinzon@amazon.com/
Arthur Kiyanovski (8):
ptp: Add ioctls for PHC timestamps with quality attributes
selftests/ptp: Extract print_system_timestamp helper in testptp
selftests/ptp: Add testptp support for attributes ioctls
ptp: ptp_vmclock: Implement attributes ioctls
net: ena: PHC: Check return code before setting timestamp output
net: ena: Update PHC admin interface for error bound support
net: ena: Add error bound to PHC communication layer
net: ena: Implement gettimexattrs64 callback for PTP attributes
.../device_drivers/ethernet/amazon/ena.rst | 2 +
.../net/ethernet/amazon/ena/ena_admin_defs.h | 17 +-
drivers/net/ethernet/amazon/ena/ena_com.c | 47 ++--
drivers/net/ethernet/amazon/ena/ena_com.h | 5 +-
drivers/net/ethernet/amazon/ena/ena_debugfs.c | 3 +
drivers/net/ethernet/amazon/ena/ena_phc.c | 67 +++++-
drivers/ptp/ptp_chardev.c | 137 ++++++++++-
drivers/ptp/ptp_clock.c | 4 +-
drivers/ptp/ptp_vmclock.c | 195 +++++++++++++--
include/linux/ptp_clock_kernel.h | 30 +++
include/uapi/linux/ptp_clock.h | 225 +++++++++++++++++-
tools/testing/selftests/ptp/testptp.c | 175 ++++++++++----
12 files changed, 799 insertions(+), 108 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Ethan Nelson-Moore @ 2026-04-30 1:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, stable, Yibo Dong, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, MD Danish Anwar, Vadim Fedorenko
In-Reply-To: <20260429175421.014bb28f@kernel.org>
On Wed, Apr 29, 2026 at 5:54 PM Jakub Kicinski <kuba@kernel.org> wrote:
> I'm having second thoughts about this. I'm worried users will come to
> expect that drivers are marked as BROKEN until such time that they
> can be considered a sufficiently complete replacement for an OOT /
> vendor driver. This will be highly subjective.
Hi, Jakub,
I understand your concern, but there is precedent for doing this when
the driver doesn't work at all.
The ntsync driver was marked as broken in commit f5b335dc025c ("misc:
ntsync: mark driver as "broken" to prevent from building") until it
was fully merged. The BROKEN dependency was then removed in commit
c301e1fefc2d ("ntsync: No longer depend on BROKEN.")
If it were my decision, I would remove BROKEN from this driver once it
supports a stable network connection, and perhaps also once it
survives suspends and resumes, since that is expected in modern
desktop use cases. I think that is a fairly objective reading of the
word BROKEN.
It might also be a good idea to agree on expected uses of
CONFIG_BROKEN and document them in init/Kconfig.
Currently it says:
This option allows you to choose whether you want to try to
compile (and fix) old drivers that haven't been updated to
new infrastructure.
which does not fully encompass what it is used for.
Ethan
^ permalink raw reply
* Re: [PATCH net 1/2] ip6: vti: Use ip6_tnl.net in vti6_changelink().
From: Jakub Kicinski @ 2026-04-30 1:18 UTC (permalink / raw)
To: maoyixie.tju
Cc: Jakub Kicinski, netdev, kuniyu, shaw.leon, davem, edumazet,
pabeni, dsahern, kuznet, linux-kernel, stable, security
In-Reply-To: <20260428110713.2550315-2-maoyixie.tju@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
ip6: vti: Use ip6_tnl.net in vti6_changelink().
After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of
rtnl_link_ops"), vti6_newlink() correctly resolves the per-netns vti6
hash via link_net. vti6_changelink() and vti6_update() were not
converted in that series and still read dev_net(dev) /
dev_net(t->dev), which diverge from the device's creation netns
after IFLA_NET_NS_FD migration. The result is a stale per-netns hash
entry; cleanup_net() of the original netns then walks freed memory.
> diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
> index ad5290be4dd6..dcb257411d6e 100644
> --- a/net/ipv6/ip6_vti.c
> +++ b/net/ipv6/ip6_vti.c
> @@ -722,10 +722,11 @@ vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p,
> static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p,
> bool keep_mtu)
> {
> - struct net *net = dev_net(t->dev);
> - struct vti6_net *ip6n = net_generic(net, vti6_net_id);
> + struct net *net = t->net;
> + struct vti6_net *ip6n;
> int err;
Does this fix introduce a regression by leaving a loophole in
vti6_siocdevprivate()?
While vti6_changelink() and vti6_update() now correctly use t->net,
vti6_siocdevprivate() still uses dev_net(dev) to locate the tunnel during
a tunnel modification ioctl:
net/ipv6/ip6_vti.c:vti6_siocdevprivate() {
...
struct net *net = dev_net(dev);
...
case SIOCCHGTUNNEL:
...
t = vti6_locate(net, &p1, cmd == SIOCADDTUNNEL);
if (dev != ip6n->fb_tnl_dev && cmd == SIOCCHGTUNNEL) {
if (t) {
if (t->dev != dev) {
err = -EEXIST;
break;
}
} else
t = netdev_priv(dev);
err = vti6_update(t, &p1, false);
}
...
}
Because the collision check occurs in the new namespace (dev_net(dev)), but
vti6_update() now modifies the original namespace's hash table (t->net),
could an attacker in the new namespace configure their tunnel to perfectly
match the parameters of an existing victim tunnel in the original namespace?
Since the check in the new namespace finds no collision, it seems it bypasses
the error check. Then vti6_update() prepends the attacker's tunnel
into the original namespace's hash table, which might allow intercepting or
hijacking traffic destined for the victim tunnel.
Should vti6_siocdevprivate() also be updated to use t->net for collision
checks to prevent cross-namespace traffic hijacking?
--
pw-bot: cr
^ permalink raw reply
* [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Eric Biggers @ 2026-04-30 1:15 UTC (permalink / raw)
To: linux-crypto, Herbert Xu
Cc: linux-doc, linux-api, linux-kernel, netdev, Linus Torvalds,
Eric Biggers
AF_ALG is almost completely unnecessary, and it exposes a massive attack
surface that hasn't been standing up to modern vulnerability discovery
tools. The latest one even has its own website, providing a small
Python script that reliably roots most Linux distros: https://copy.fail/
This isn't sustainable, especially as LLMs have accelerated the rate the
vulnerabilities are coming in. The effort that is being put into this
thing is vastly disproportional to the few programs that actually use
it, and those programs would be better served by userspace code anyway.
These issues have been noted in many mailing list discussions already.
But until now they haven't been reflected in the documentation or
kconfig menu itself, and the vulnerabilities are still coming in.
Let's go ahead and document the deprecation.
This isn't intended to change anything overnight. After all, most Linux
distros won't be able to disable the kconfig options quite yet, mainly
because of iwd. But this should create a bit more impetus for these
userspace programs to be fixed, and the documentation update should also
help prevent more users from appearing.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
This patch is targeting crypto/master
Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
crypto/Kconfig | 69 ++++++++++++++++------
2 files changed, 113 insertions(+), 38 deletions(-)
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index 021759198fe7..c39f5c79a5b7 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -2,30 +2,72 @@ User Space Interface
====================
Introduction
------------
-The concepts of the kernel crypto API visible to kernel space is fully
-applicable to the user space interface as well. Therefore, the kernel
-crypto API high level discussion for the in-kernel use cases applies
-here as well.
-
-The major difference, however, is that user space can only act as a
-consumer and never as a provider of a transformation or cipher
-algorithm.
-
-The following covers the user space interface exported by the kernel
-crypto API. A working example of this description is libkcapi that can
-be obtained from [1]. That library can be used by user space
-applications that require cryptographic services from the kernel.
-
-Some details of the in-kernel kernel crypto API aspects do not apply to
-user space, however. This includes the difference between synchronous
-and asynchronous invocations. The user space API call is fully
-synchronous.
-
-[1] https://www.chronox.de/libkcapi/index.html
+AF_ALG provides unprivileged userspace programs access to arbitrary hash,
+symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
+code.
+
+AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
+most kernel developers now consider it to be a mistake.
+
+AF_ALG continues to be supported only for backwards compatibility. On systems
+where no programs using AF_ALG remain, the support for it should be disabled by
+disabling ``CONFIG_CRYPTO_USER_API_*``.
+
+Deprecation
+-----------
+
+AF_ALG was originally intended to provide userspace programs access to crypto
+accelerators that they wouldn't otherwise have access to.
+
+However, that capability turned out to not be useful on very many systems. More
+significantly, the actual implementation exposes a vastly greater amount of
+functionality than that. It actually provides access to all software algorithms.
+
+This includes arbitrary compositions of different algorithms created via a
+complex template system, as well as algorithms that only make sense as internal
+implementation details of other algorithms. It also includes full zero-copy
+support, which is difficult for the kernel to implement securely.
+
+Ultimately, these algorithms are just math computations. They use the same
+instructions that userspace programs already have access to, just accessed in a
+much more convoluted and less efficient way.
+
+Indeed, userspace code is nearly always what is being used anyway. These same
+algorithms are widely implemented in userspace crypto libraries.
+
+Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools
+such as syzbot and large language models. It receives a steady stream of CVEs.
+Some of the examples include:
+
+- CVE-2026-31677
+- CVE-2026-31431 (https://copy.fail)
+- CVE-2025-38079
+- CVE-2025-37808
+- CVE-2024-26824
+- CVE-2022-48781
+- CVE-2019-8912
+- CVE-2018-14619
+- CVE-2017-18075
+- CVE-2017-17806
+- CVE-2017-17805
+- CVE-2016-10147
+- CVE-2015-8970
+- CVE-2015-3331
+- CVE-2014-9644
+- CVE-2013-7421
+- CVE-2011-4081
+
+It is recommended that, whenever possible, userspace programs be migrated to
+userspace crypto code (which again, is what is normally used anyway) and
+``CONFIG_CRYPTO_USER_API_*`` be disabled. On systems that use SELinux, SELinux
+can also be used to restrict the use of AF_ALG to trusted programs.
+
+The remainder of this documentation provides the historical documentation for
+the deprecated AF_ALG interface.
User Space API General Remarks
------------------------------
The kernel crypto API is accessible from user space. Currently, the
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 103d1f58cb7c..6cd1c478d4be 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1278,48 +1278,72 @@ config CRYPTO_DF80090A
tristate
select CRYPTO_AES
select CRYPTO_CTR
endmenu
-menu "Userspace interface"
+menu "Userspace interface (deprecated)"
config CRYPTO_USER_API
tristate
config CRYPTO_USER_API_HASH
- tristate "Hash algorithms"
+ tristate "Hash algorithms (deprecated)"
depends on NET
select CRYPTO_HASH
select CRYPTO_USER_API
help
- Enable the userspace interface for hash algorithms.
+ Enable the AF_ALG userspace interface for hash algorithms. This
+ provides unprivileged userspace programs access to arbitrary hash
+ algorithms implemented in the kernel's privileged execution context.
- See Documentation/crypto/userspace-if.rst and
- https://www.chronox.de/libkcapi/html/index.html
+ This interface is deprecated and is supported only for backwards
+ compatibility. It regularly has vulnerabilities, and the capabilities
+ it provides are redundant with userspace crypto libraries.
+
+ Enable this only if needed for support for a program that hasn't yet
+ been converted to userspace crypto, for example iwd.
+
+ See also Documentation/crypto/userspace-if.rst
config CRYPTO_USER_API_SKCIPHER
- tristate "Symmetric key cipher algorithms"
+ tristate "Symmetric key cipher algorithms (deprecated)"
depends on NET
select CRYPTO_SKCIPHER
select CRYPTO_USER_API
help
- Enable the userspace interface for symmetric key cipher algorithms.
+ Enable the AF_ALG userspace interface for symmetric key algorithms.
+ This provides unprivileged userspace programs access to arbitrary
+ symmetric key algorithms implemented in the kernel's privileged
+ execution context.
+
+ This interface is deprecated and is supported only for backwards
+ compatibility. It regularly has vulnerabilities, and the capabilities
+ it provides are redundant with userspace crypto libraries.
+
+ Enable this only if needed for support for a program that hasn't yet
+ been converted to userspace crypto, for example iwd, or cryptsetup
+ with certain algorithms.
- See Documentation/crypto/userspace-if.rst and
- https://www.chronox.de/libkcapi/html/index.html
+ See also Documentation/crypto/userspace-if.rst
config CRYPTO_USER_API_RNG
- tristate "RNG (random number generator) algorithms"
+ tristate "Random number generation algorithms (deprecated)"
depends on NET
select CRYPTO_RNG
select CRYPTO_USER_API
help
- Enable the userspace interface for RNG (random number generator)
- algorithms.
+ Enable the AF_ALG userspace interface for random number generation
+ (RNG) algorithms. This provides unprivileged userspace programs
+ access to arbitrary RNG algorithms implemented in the kernel's
+ privileged execution context.
- See Documentation/crypto/userspace-if.rst and
- https://www.chronox.de/libkcapi/html/index.html
+ This interface is deprecated and is supported only for backwards
+ compatibility. It regularly has vulnerabilities, and the capabilities
+ it provides are redundant with userspace crypto libraries as well as
+ the normal kernel RNG (e.g., /dev/urandom and getrandom(2)).
+
+ See also Documentation/crypto/userspace-if.rst
config CRYPTO_USER_API_RNG_CAVP
bool "Enable CAVP testing of DRBG"
depends on CRYPTO_USER_API_RNG && CRYPTO_DRBG
help
@@ -1330,20 +1354,29 @@ config CRYPTO_USER_API_RNG_CAVP
This should only be enabled for CAVP testing. You should say
no unless you know what this is.
config CRYPTO_USER_API_AEAD
- tristate "AEAD cipher algorithms"
+ tristate "AEAD cipher algorithms (deprecated)"
depends on NET
select CRYPTO_AEAD
select CRYPTO_SKCIPHER
select CRYPTO_USER_API
help
- Enable the userspace interface for AEAD cipher algorithms.
+ Enable the AF_ALG userspace interface for authenticated encryption
+ with associated data (AEAD) algorithms. This provides unprivileged
+ userspace programs access to arbitrary AEAD algorithms implemented in
+ the kernel's privileged execution context.
+
+ This interface is deprecated and is supported only for backwards
+ compatibility. It regularly has vulnerabilities, and the capabilities
+ it provides are redundant with userspace crypto libraries.
+
+ Enable this only if needed for support for a program that hasn't yet
+ been converted to userspace crypto, for example iwd.
- See Documentation/crypto/userspace-if.rst and
- https://www.chronox.de/libkcapi/html/index.html
+ See also Documentation/crypto/userspace-if.rst
config CRYPTO_USER_API_ENABLE_OBSOLETE
bool "Obsolete cryptographic algorithms"
depends on CRYPTO_USER_API
default y
base-commit: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Jakub Kicinski @ 2026-04-30 1:27 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: netdev, stable, Yibo Dong, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, MD Danish Anwar, Vadim Fedorenko
In-Reply-To: <CADkSEUiRwto-14zkER30WJdiQa2b+OGOZ+2S50pq4doJ37X70Q@mail.gmail.com>
On Wed, 29 Apr 2026 18:13:46 -0700 Ethan Nelson-Moore wrote:
> On Wed, Apr 29, 2026 at 5:54 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > I'm having second thoughts about this. I'm worried users will come to
> > expect that drivers are marked as BROKEN until such time that they
> > can be considered a sufficiently complete replacement for an OOT /
> > vendor driver. This will be highly subjective.
>
> I understand your concern, but there is precedent for doing this when
> the driver doesn't work at all.
>
> The ntsync driver was marked as broken in commit f5b335dc025c ("misc:
> ntsync: mark driver as "broken" to prevent from building") until it
> was fully merged. The BROKEN dependency was then removed in commit
> c301e1fefc2d ("ntsync: No longer depend on BROKEN.")
ntsync is mere 1.2kLoC, that's 10x smaller than typical networking
driver these days, and even (slightly) smaller than rnpgbe(!)
Most in-tree networking drivers play constant catch-up with the OOT
version so they are never "fully merged".
> If it were my decision, I would remove BROKEN from this driver once it
> supports a stable network connection, and perhaps also once it
> survives suspends and resumes, since that is expected in modern
> desktop use cases. I think that is a fairly objective reading of the
> word BROKEN.
That'd require us to know if the device is going to be used on
desktop because for datacenter NICs suspend/resume does not matter.
> It might also be a good idea to agree on expected uses of
> CONFIG_BROKEN and document them in init/Kconfig.
> Currently it says:
> This option allows you to choose whether you want to try to
> compile (and fix) old drivers that haven't been updated to
> new infrastructure.
> which does not fully encompass what it is used for.
Maybe it was written in simpler times, maybe the help message was
aspirational to begin with..
^ permalink raw reply
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Jakub Kicinski @ 2026-04-30 1:29 UTC (permalink / raw)
To: Andrew Lunn
Cc: Daniel Golle, chester.a.unal, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <52d69a5d-a951-4a65-a947-7aaf41bc3daf@lunn.ch>
On Thu, 30 Apr 2026 02:12:47 +0200 Andrew Lunn wrote:
> > > The priv->bus pointer is initialized during probe. However,
> > > INIT_DELAYED_WORK() is only called in mt753x_setup(), which might never
> > > execute if the DSA tree remains incomplete.
>
> The opposite of .setup() is .teardown(). So if the delayed work is
> setup is setup() it should be cancelled in .teardown, to keeps things
> symmetric.
The code does that, but also cancels again in remove.
IDK if that's just "for good measure", or motivated by a previous AI
complaint :(
But I think your point stands, as is the driver is not symmetric,
if we want to cancel in .remove it has to init in .probe.
^ permalink raw reply
* Re: [PATCH net-next v3] net: mdio: drop unneeded dependency on OF_GPIO
From: patchwork-bot+netdevbpf @ 2026-04-30 1:30 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, brgl,
netdev, linux-kernel
In-Reply-To: <20260428093338.35043-1-bartosz.golaszewski@oss.qualcomm.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 11:33:38 +0200 you wrote:
> OF_GPIO is selected automatically on all OF systems. Any symbols it
> controls also provide stubs so there's really no reason to select it
> explicitly.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Changes in v3:
> - Send the next patch separately so that it can be picked up
> - Link to v2: https://patch.msgid.link/20260316-gpio-of-kconfig-v2-0-de2f4b00a0e4@oss.qualcomm.com
>
> [...]
Here is the summary with links:
- [net-next,v3] net: mdio: drop unneeded dependency on OF_GPIO
https://git.kernel.org/netdev/net-next/c/c13581876f2c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [RFC PATCH net-next 0/3] netns: optionally inherit IPv4 TCP sysctls from old net
From: nmreadelf @ 2026-04-30 1:30 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, corbet, dsahern
Cc: horms, chia-yu.chang, idosch, ij, brauner, jack, kuniyu, jlayton,
netdev, linux-doc, linux-kernel, kong414, lance.yang, leon.hwang
a new network namespace starts with built-in TCP defaults.
In container-heavy setups, operators often tune TCP sysctls in init_net and then
need to re-apply the same values for each new netns.
This series adds an opt-in mechanism to initialize per-netns IPv4 TCP sysctl
settings from init_net at netns creation time.
Behavior:
Default is unchanged.
When net.ipv4.netns_inherit_tcp_sysctls=1, new netns inherit
TCP sysctl from old_net.
nmreadelf (3):
ipv4: netns: group copyable TCP sysctls in netns_ipv4
net: ipv4: add netns_inherit_tcp_sysctls sysctl
tcp: netns: optionally inherit IPv4 TCP sysctls from parent netns
.../net_cachelines/netns_ipv4_sysctl.rst | 25 +++----
include/net/netns/ipv4.h | 33 +++++----
net/core/net_namespace.c | 72 +++++++++++++++++++
net/ipv4/sysctl_net_ipv4.c | 9 +++
4 files changed, 114 insertions(+), 25 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH net 2/2] ip6_gre: Use cached t->net in ip6erspan_changelink().
From: Jakub Kicinski @ 2026-04-30 1:18 UTC (permalink / raw)
To: maoyixie.tju
Cc: Jakub Kicinski, netdev, kuniyu, shaw.leon, davem, edumazet,
pabeni, dsahern, kuznet, linux-kernel, stable, security
In-Reply-To: <20260428110713.2550315-3-maoyixie.tju@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
ip6_gre: Use cached t->net in ip6erspan_changelink().
This commit fixes an issue where ip6erspan_changelink() uses the device
creation netns instead of the per-netns ip6gre hash. This ensures the tunnel
is inserted into the correct hash, avoiding a stale entry and subsequent
use-after-free during netns destruction.
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 63fc8556b475..c5978e0bdfe3 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -2262,7 +2262,8 @@ static int ip6erspan_changelink(struct net_device *dev, struct nlattr *tb[],
> struct nlattr *data[],
> struct netlink_ext_ack *extack)
> {
> - struct ip6gre_net *ign = net_generic(dev_net(dev), ip6gre_net_id);
> + struct ip6_tnl *nt = netdev_priv(dev);
> + struct ip6gre_net *ign = net_generic(nt->net, ip6gre_net_id);
> struct __ip6_tnl_parm p;
> struct ip6_tnl *t;
While reviewing this area, I noticed a regression further down in
ip6erspan_changelink() regarding the metadata tunnel unlinking.
If an existing ERSPAN tunnel with metadata collection enabled is modified via
a netlink changelink request to disable metadata collection, does the unlink
sequence clear the correct pointer?
Looking at the rest of ip6erspan_changelink():
ip6gre_tunnel_unlink_md(ign, t);
ip6gre_tunnel_unlink(ign, t);
ip6erspan_tnl_change(t, &p, !tb[IFLA_MTU]);
ip6erspan_tunnel_link_md(ign, t);
Because ip6gre_tunnel_unlink_md() is called instead of
ip6erspan_tunnel_unlink_md(), it evaluates the old collect_md state but
clears ign->collect_md_tun instead of ign->collect_md_tun_erspan.
This seems to leave ign->collect_md_tun_erspan pointing to the tunnel.
Since ip6erspan_tnl_change() updates the parameters to disable collect_md,
the subsequent call to ip6erspan_tunnel_link_md() will skip updating the
pointer.
When the tunnel is eventually deleted, ip6erspan_tunnel_unlink_md() would
be bypassed entirely because collect_md is now false.
Could this leave ign->collect_md_tun_erspan as a dangling pointer,
causing a use-after-free when an incoming ERSPAN packet triggers
ip6gre_tunnel_lookup() and dereferences it?
^ permalink raw reply
* [RFC PATCH net-next 0/3] netns: optionally inherit IPv4 TCP sysctls from old net
From: nmreadelf @ 2026-04-30 1:32 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, corbet, dsahern
Cc: horms, chia-yu.chang, idosch, ij, brauner, jack, kuniyu, jlayton,
netdev, linux-doc, linux-kernel, kong414, lance.yang, leon.hwang
In-Reply-To: <TY7PR01MB172057C053E8D550485A29A08E0352@TY7PR01MB17205.jpnprd01.prod.outlook.com>
a new network namespace starts with built-in TCP defaults.
In container-heavy setups, operators often tune TCP sysctls in init_net and then
need to re-apply the same values for each new netns.
This series adds an opt-in mechanism to initialize per-netns IPv4 TCP sysctl
settings from init_net at netns creation time.
Behavior:
Default is unchanged.
When net.ipv4.netns_inherit_tcp_sysctls=1, new netns inherit
TCP sysctl from old_net.
nmreadelf (3):
ipv4: netns: group copyable TCP sysctls in netns_ipv4
net: ipv4: add netns_inherit_tcp_sysctls sysctl
tcp: netns: optionally inherit IPv4 TCP sysctls from parent netns
.../net_cachelines/netns_ipv4_sysctl.rst | 25 +++----
include/net/netns/ipv4.h | 33 +++++----
net/core/net_namespace.c | 72 +++++++++++++++++++
net/ipv4/sysctl_net_ipv4.c | 9 +++
4 files changed, 114 insertions(+), 25 deletions(-)
--
2.47.3
^ permalink raw reply
* [RFC PATCH net-next 1/3] ipv4: netns: group copyable TCP sysctls in netns_ipv4
From: nmreadelf @ 2026-04-30 1:33 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, corbet, dsahern
Cc: horms, chia-yu.chang, idosch, ij, brauner, jack, kuniyu, jlayton,
netdev, linux-doc, linux-kernel, kong414, lance.yang, leon.hwang
In-Reply-To: <TY7PR01MB172057C053E8D550485A29A08E0352@TY7PR01MB17205.jpnprd01.prod.outlook.com>
Group the TCP sysctl members into tcp_sysctl using struct_group().
This makes the memcpy and sizeof boundaries clear in follow-up
patches, avoids relying on writes across neighboring
members, and improves readability.
---
.../net_cachelines/netns_ipv4_sysctl.rst | 25 ++++++++-------
include/net/netns/ipv4.h | 32 +++++++++++--------
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
index beaf1880a19b..f6edf02618fa 100644
--- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
+++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
@@ -43,23 +43,20 @@ u32 ip_rt_min_pmtu
int ip_rt_mtu_expires
int ip_rt_min_advmss
struct_local_ports ip_local_ports
-u8 sysctl_tcp_ecn
-u8 sysctl_tcp_ecn_fallback
u8 sysctl_ip_default_ttl ip4_dst_hoplimit/ip_select_ttl
u8 sysctl_ip_no_pmtu_disc
-u8 sysctl_ip_fwd_use_pmtu read_mostly ip_dst_mtu_maybe_forward/ip_skb_dst_mtu
u8 sysctl_ip_fwd_update_priority ip_forward
u8 sysctl_ip_nonlocal_bind
u8 sysctl_ip_autobind_reuse
u8 sysctl_ip_dynaddr
-u8 sysctl_ip_early_demux read_mostly ip(6)_rcv_finish_core
u8 sysctl_raw_l3mdev_accept
-u8 sysctl_tcp_early_demux read_mostly ip(6)_rcv_finish_core
u8 sysctl_udp_early_demux
u8 sysctl_nexthop_compat_mode
u8 sysctl_fwmark_reflect
+.. struct_group(tcp_sysctl) bulk-copied via memcpy() in tcp_sk_init()
+u8 sysctl_tcp_ecn
+u8 sysctl_tcp_ecn_fallback
u8 sysctl_tcp_fwmark_accept
-u8 sysctl_tcp_l3mdev_accept read_mostly __inet6_lookup_established/inet_request_bound_dev_if
u8 sysctl_tcp_mtu_probing
int sysctl_tcp_mtu_probe_floor
int sysctl_tcp_base_mss
@@ -85,6 +82,7 @@ unsigned_int sysctl_tcp_notsent_lowat rea
u8 sysctl_tcp_sack tcp_syn_options
u8 sysctl_tcp_window_scaling tcp_syn_options,tcp_parse_options
u8 sysctl_tcp_timestamps
+u8 sysctl_netns_inherit_tcp_sysctls read_mostly tcp_schedule_loss_probe(tcp_write_xmit)
u8 sysctl_tcp_early_retrans read_mostly tcp_schedule_loss_probe(tcp_write_xmit)
u32 sysctl_tcp_rto_max_ms
u8 sysctl_tcp_recovery tcp_fastretrans_alert
@@ -123,18 +121,21 @@ unsigned_long sysctl_tcp_comp_sack_delay_ns
unsigned_long sysctl_tcp_comp_sack_slack_ns __tcp_ack_snd_check
int sysctl_max_syn_backlog
int sysctl_tcp_fastopen
-struct_tcp_congestion_ops tcp_congestion_control init_cc
-struct_tcp_fastopen_context tcp_fastopen_ctx
unsigned_int sysctl_tcp_fastopen_blackhole_timeout
-atomic_t tfo_active_disable_times
-unsigned_long tfo_active_disable_stamp
-u32 tcp_challenge_timestamp
-u32 tcp_challenge_count
u8 sysctl_tcp_plb_enabled
u8 sysctl_tcp_plb_idle_rehash_rounds
u8 sysctl_tcp_plb_rehash_rounds
u8 sysctl_tcp_plb_suspend_rto_sec
int sysctl_tcp_plb_cong_thresh
+u8 sysctl_tcp_shrink_window
+u8 sysctl_tcp_syn_linear_timeouts
+.. end_of(tcp_sysctl)
+struct_tcp_congestion_ops tcp_congestion_control init_cc
+struct_tcp_fastopen_context tcp_fastopen_ctx
+atomic_t tfo_active_disable_times
+unsigned_long tfo_active_disable_stamp
+u32 tcp_challenge_timestamp
+u32 tcp_challenge_count
int sysctl_udp_wmem_min
int sysctl_udp_rmem_min
u8 sysctl_fib_notify_on_flag_change
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 2dbd46fc4734..53b180cc7a94 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -116,7 +116,6 @@ struct netns_ipv4 {
#endif
bool fib_has_custom_local_routes;
bool fib_offload_disabled;
- u8 sysctl_tcp_shrink_window;
#ifdef CONFIG_IP_ROUTE_CLASSID
atomic_t fib_num_tclassid_users;
#endif
@@ -149,11 +148,6 @@ struct netns_ipv4 {
struct local_ports ip_local_ports;
- u8 sysctl_tcp_ecn;
- u8 sysctl_tcp_ecn_option;
- u8 sysctl_tcp_ecn_option_beacon;
- u8 sysctl_tcp_ecn_fallback;
-
u8 sysctl_ip_default_ttl;
u8 sysctl_ip_no_pmtu_disc;
u8 sysctl_ip_fwd_update_priority;
@@ -169,6 +163,14 @@ struct netns_ipv4 {
u8 sysctl_nexthop_compat_mode;
u8 sysctl_fwmark_reflect;
+
+ /* TCP sysctl fields enclosed in tcp_sysctl group are copied
+ * using a single memcpy() in tcp_sk_init()
+ */
+ struct_group(tcp_sysctl, u8 sysctl_tcp_ecn;
+ u8 sysctl_tcp_ecn_option;
+ u8 sysctl_tcp_ecn_option_beacon;
+ u8 sysctl_tcp_ecn_fallback;
u8 sysctl_tcp_fwmark_accept;
u8 sysctl_tcp_mtu_probing;
int sysctl_tcp_mtu_probe_floor;
@@ -227,24 +229,28 @@ struct netns_ipv4 {
unsigned long sysctl_tcp_comp_sack_slack_ns;
int sysctl_max_syn_backlog;
int sysctl_tcp_fastopen;
- const struct tcp_congestion_ops __rcu *tcp_congestion_control;
- struct tcp_fastopen_context __rcu *tcp_fastopen_ctx;
unsigned int sysctl_tcp_fastopen_blackhole_timeout;
- atomic_t tfo_active_disable_times;
- unsigned long tfo_active_disable_stamp;
- u32 tcp_challenge_timestamp;
- u32 tcp_challenge_count;
u8 sysctl_tcp_plb_enabled;
u8 sysctl_tcp_plb_idle_rehash_rounds;
u8 sysctl_tcp_plb_rehash_rounds;
u8 sysctl_tcp_plb_suspend_rto_sec;
int sysctl_tcp_plb_cong_thresh;
+ u8 sysctl_tcp_shrink_window;
+ u8 sysctl_tcp_syn_linear_timeouts;
+
+ ); /* end tcp_sysctl group */
+
+ const struct tcp_congestion_ops __rcu *tcp_congestion_control;
+ struct tcp_fastopen_context __rcu *tcp_fastopen_ctx;
+ atomic_t tfo_active_disable_times;
+ unsigned long tfo_active_disable_stamp;
+ u32 tcp_challenge_timestamp;
+ u32 tcp_challenge_count;
int sysctl_udp_wmem_min;
int sysctl_udp_rmem_min;
u8 sysctl_fib_notify_on_flag_change;
- u8 sysctl_tcp_syn_linear_timeouts;
#ifdef CONFIG_NET_L3_MASTER_DEV
u8 sysctl_udp_l3mdev_accept;
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox