The #ext4 data corruption issue[1] in #Linux#kernel v6.1.64 and v6.1.65 that was fixed with #LinuxKernel 6.1.66[2] apparently hit #Debian 12.3 bookworm point release[3]. Fixes are in the works, but preparing them will take a bit[4].
"""MAINTAINERS: change reiserfs status to obsolete
Reiserfs file system is no longer supported and is going to be removed in 2025 as stated in commit eb103a51640e ("reiserfs: Deprecate reiserfs").""" #LinuxKernel
Would be even better if a few people could play this through – but I guess chances are slim anyone seeing this currently has a need for that. #LinuxKernel
Linus re-sorted the #Linux#kernel's MAINTAINERS file again and had this to say:
The answer is "No. No we cannot".
I suggest that all kernel developers will need weekly training sessions, involving a lot of Big Bird and Sesame Street. And at the yearly maintainer summit, we will all sing the alphabet song together.```
😂
<https://git.kernel.org/torvalds/c/c192ac7357683f78c2e6d6e75adfcc29deb8c4ae> #LinuxKernel
This for example is of interest for software like postgresql, as it makes it "a lot easier to avoid deadlocks in concurrent programs that have their own buffer pool […] The ability to wait for a lock and IO completions at the same time provides an efficient way to avoid such deadlocks […]". It furthermore "[…] allows for more efficient directed wakeups. […]" #LinuxKernel
I know it's a long shot, but is anyone here familiar with the mechanics involved in the scheduling of isochronous USB transfers in the linux kernel? I'm running into some weird problems where the URBs fail to submit because the EHCI scheduler reports that I'm out of bandwidth depending on which order they're submitted in. This is specifically related to USB audio, where sometimes the ISO OUT URBs are submitted before the ISO IN ones when starting a full duplex stream in which case it works fine, but for some reason it fails with cannot submit urb 0, error -28: not enough bandwidth when submitting them the other way around.
What people seem to forget is that free software does not mean that people will fix your software for your use case for free. It means that *you* are free to fix the software, or to pay someone to fix the software in question.
This is not news, of course, but it's interesting to see it spelled out. Are there other pages/lists like this? Maybe even a cap-to-root script/program..?
"#StackRot is a #Linux#kernel vulnerability found in the memory management subsystem [of 6.1 - 6.4], it affects almost all configurations and requires minimal capabilities to trigger"
As #Linux#kernel community, process, and quality problems are discussed due to critical toots from @marcan a quick reminder:
Many problems currently discussed are well known for years; below screenshot from the slide deck mentioned at the start of https://lwn.net/Articles/799134/ shows that.
Things didn't improve much since then. The main reason for that IMHO is not "resistance to change among the elders" – it's lack of funding for people that work out and establish better workflows. #LinuxKernel
'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
Annoyed by having to put #sudo in front on #dmesg[1]?
Then use this instead[2]:
$ journalctl -k
It should work if the user executing this is a member of the groups "systemd-journal", "adm", or "wheel".
[1] which is the case if CONFIG_SECURITY_DMESG_RESTRICT is turned on in your #Linux#kernel's .config – which #Fedora recently switched on, something many other distros did already a while ago.
[2] works for the common case, for some fancier stuff you might still need dmesg #LinuxKernel
Lasse Collin's patch-series updating the #LinuxKernel's #xz code that a few days ago hit #linux-next was dropped for now until backdooring of upstream xz is understood better: