> So per that messaging, the UDP-Lite code really hasn't been used in years and doing away with it can net some measurable (+3~10% packets per second) for other UDP workloads.
Often times removing deprecated code is purely for developer purity. You just don’t want it lying around.
But 3-10% pps improvement is quite an achievement for removing some branches.
It's interesting how they found the unused code. Are there enough real world participants who would allow tracing in order to understand what other codeblocks are unused in the real world and put in deprecation notices? I kind of wonder what percentage of the code is nominally functional but never actually used even in the wild.
> It's interesting how they found the unused code.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
I must admit just from reading the description, it doesn't sound that the correct inference is that it's never been used.
"In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem." to me reads that if the total memory usage never exceeded that threshold then the bug wouldn't trigger. So, wouldn't this bug only affect people who changed that threshold down below the current usage? Because otherwise, usage wouldn't go above the threshold anyway?
And just because the kernel is logging a deprecation notice, there's no guarantee that anyone would ever see that, depending how often it was logged.
But that said, I'd never even heard of this feature, and wouldn't be at all surprised if many routers hadn't just silently dropped these packets anyway because they didn't recognise the protocol version.
Ultimately Linux development is driven by people who participate on LKML. If you are not willing to at least follow deprecations and show up for discussions then you are at the mercy of those who do
Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable. I'm sure the kernel's deprecation policy is more detailed than "show up on LKML or else".
> Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable.
Breakages to userspace happen somewhat regularly from what I get, but its more of a case of "If the tree falls in the forest and nobody complains it didn't happen". Though its more that one should at least make sure in some form or fashion that it won't at least affect anyone.
> So per that messaging, the UDP-Lite code really hasn't been used in years and doing away with it can net some measurable (+3~10% packets per second) for other UDP workloads.
Often times removing deprecated code is purely for developer purity. You just don’t want it lying around.
But 3-10% pps improvement is quite an achievement for removing some branches.
It's interesting how they found the unused code. Are there enough real world participants who would allow tracing in order to understand what other codeblocks are unused in the real world and put in deprecation notices? I kind of wonder what percentage of the code is nominally functional but never actually used even in the wild.
> It's interesting how they found the unused code.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
I must admit just from reading the description, it doesn't sound that the correct inference is that it's never been used.
"In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem." to me reads that if the total memory usage never exceeded that threshold then the bug wouldn't trigger. So, wouldn't this bug only affect people who changed that threshold down below the current usage? Because otherwise, usage wouldn't go above the threshold anyway?
And just because the kernel is logging a deprecation notice, there's no guarantee that anyone would ever see that, depending how often it was logged.
But that said, I'd never even heard of this feature, and wouldn't be at all surprised if many routers hadn't just silently dropped these packets anyway because they didn't recognise the protocol version.
Ultimately Linux development is driven by people who participate on LKML. If you are not willing to at least follow deprecations and show up for discussions then you are at the mercy of those who do
Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable. I'm sure the kernel's deprecation policy is more detailed than "show up on LKML or else".
> Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable.
Breakages to userspace happen somewhat regularly from what I get, but its more of a case of "If the tree falls in the forest and nobody complains it didn't happen". Though its more that one should at least make sure in some form or fashion that it won't at least affect anyone.
Source: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-n...
So much for never breaking userspace.