A pile of stable kernel updates
Posted Nov 28, 2023 21:51 UTC (Tue)
by alspnost (guest, #2763)
[Link] (2 responses)
Posted Nov 28, 2023 22:11 UTC (Tue)
by hmh (subscriber, #3838)
[Link] (1 responses)
Posted Nov 29, 2023 19:20 UTC (Wed)
by alspnost (guest, #2763)
[Link]
Posted Nov 28, 2023 23:58 UTC (Tue)
by npws (subscriber, #168248)
[Link] (5 responses)
There's a lot of patches fixing theoretical race conditions (without the explanation required by stable kernel rules), f.i. all the regular occuring "annotate data races" patches. I see "fix %s null argument warning", "Optimize in_task() and in_interrupt() a bit", multiple "Fix kernel-doc warnings in ...", "net: ethtool: Fix documentation of ethtool_sprintf()" etc etc, and that's just scrolling through the first few pages.
Basically nowadays it seems anything is thrown into stable without any vetting at all. That makes it hard to a) trust these kernels to not break things and b) check the changelog if it might contain important fixes for the systems you care about.
Posted Nov 29, 2023 8:27 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
I remember a load of complaints about how subsystems were flagging anything and everything "for stable", and unfortunately, Greg doesn't have the advantage of Linus' -rc series where all the broken stuff that slips through the net gets weeded out.
The stable gardeners aren't weeding properly ...
Cheers,
Posted Nov 29, 2023 11:08 UTC (Wed)
by MarcB (guest, #101804)
[Link] (3 responses)
A data race is only theoretical until someone manages to exploit it or until someone is able to trace a "random" data corruption or crash to it. I am absolutely in favor of fixing such bugs in stable.
The documentation fixes you mention are safe by definition. I suspect they got it because they were part of a pull request that also fixed a bug. It would have been useless work to split them.
The optimization you mention indeed sound questionable, but it is possible this is just an euphemism for an actual security issue.
Posted Nov 29, 2023 14:59 UTC (Wed)
by npws (subscriber, #168248)
[Link] (2 responses)
Regarding the data races, it's a trade-off. The ones fixed by Eric are simple and have no real risk of regression, so yeah, let's fix those. Others are more questionable, if they require larger code and locking changes.
Regarding documentation changes, sure, they have no risk of regression, they still clutter up the changelog and make it harder to spot the really important fixes. I actually do read those because following "All users of the 6.6 kernel series must upgrade" has bitten me more than once, exactly because people do send way too many "fixes" to -stable.
Posted Nov 30, 2023 0:11 UTC (Thu)
by sashal (✭ supporter ✭, #81842)
[Link] (1 responses)
In general, we'll take dependencies over trying to resolve (non trivial) conflicts, or major rewrites to backport a patch because of two main reasons:
1. It makes future backports easier. If we diverge from Linus's tree, future patches that touch the same code will become harder and harder to apply.
Going back to the kernel doc patches you've brought up, the have the following tag added at the bottom:
Stable-dep-of: 157a3537d6bc ("apparmor: Fix regression in mount mediation")
To say "Hey, we know that this kernel doc change shouldn't be in -stable, but this is why we took it anyway".
Maybe you can filter commits containing the tag for your own uses?
Posted Nov 30, 2023 2:56 UTC (Thu)
by Ranguvar (subscriber, #56734)
[Link]
I note that some of these updates went to -rc4, which is unusual. There were obviously some 'issues' to resolve, and perhaps there still are? I've not tested 6.6.3 yet, but I'll be interested to see if it fixes my Wi-Fi again (Mediatek driver). Everything up to 6.6.1 was fine, but 6.6.2 broke it completely....
A pile of stable kernel updates
A pile of stable kernel updates
Pleased to report that it does appear to have been a glitch in 6.6.2 - I have now upgraded to 6.6.3 (using Liquorix) and we're all happy again!
A pile of stable kernel updates
A pile of stable kernel updates
A pile of stable kernel updates
Wol
A pile of stable kernel updates
There are many examples of bugs not being fixed ASAP because they appeared not to be (security) relevant (see https://www.openssl.org/news/secadv/20231024.txt for a recent example).
Vetting bugs for (security) relevance typically is much, much harder than simply fixing the bug and the chance is high that vetting result is wrong anyway. I do not think this approach has worked well anywhere. (I know that many environments have policies - either self-imposed or regulatory - that make updating hard, but that really is their problem).
A pile of stable kernel updates
A pile of stable kernel updates
2. Backports tend to be incorrect more often than just backporting dependencies.
A pile of stable kernel updates