Notices by Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org), page 4

@RuiSeabra

Well, sounds like in that use-case that trick might not make sense. But that's how it sometimes is with such tricks.

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

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].

[1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/

[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=ea574927fc0bc343016ea3337fcfc0b3fb26fe08

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

[4] https://fulda.social/@Ganneff/111551628003050712

#Linux 6.6 just became a #Longterm (aka #LTS) #kernel.

The #LinuxKernel's stable team (Sasha Levin and @gregkh) just made this official by adding it to https://www.kernel.org/category/releases.html with the following change: https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=d3c85f300d9214949efae275e519f30cce155cca

Projected EOL is December 2026.

@corbet @monsieuricon

But is LKML still CCed on basically everything? I didn't check, but I got the impression that sometimes it's forgotten or omitted on purpise. If that is frequently the case I wonder if it would make more sense to create some kind of "automatically filled catch all list" that better serves the needs of those that like LKML how it is.

[if anyone things it's worth bringing this point to the discussion let me know]

@jmorris @monsieuricon

afaik @corbet still tries to skim it

@monsieuricon

sometimes I wonder if we still need LKML now that we have lore.kernel.org/all/

* LKML is CCed on a lot of stuff, but a lot of stuff it's not, so it's not a "everything" list/archive

* because so much is CCed on LKML it's impossible to read for nearly everyone, which makes it hard to see/follow stuff that has list/no better place.

Or am I missing something here?

Sooner or later the #Linux #kernel afaics will need a group of "first level bug responders" to reduce workload and noise for #LinuxKernel maintainers and developers.

E.g. a group of people that triages incoming bug reports[1] and normally only lets those through to the real developers that meet some very basic requirements.

[1] point to dupes, check if the report is sane, check if all basic information is there, ...

Remember hard to understand #LinuxKernel error messages like this:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,16)

With #Linux #kernel 6.7 those will be a little easier to understand, as the message will show the pretty name for the device it was searching for:

Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/vdb" or unknown-block(254,16)

For details see: https://git.kernel.org/torvalds/c/84d2b696236c63836011f04d13d3f09ed47fa560

@Conan_Kudo @lkundrak

It's "Co-developed-by:" in Linux:

$ git log origin/master --grep 'Co-developed-by:' --since="1 year ago" | grep 'Co-developed-by:' | wc -l
1312

$ git log origin/master --grep 'Co-developed-by:' --since="1 year ago" --oneline | wc -l
1028

"[…] Instead of accepting my [#LinuxKernel] patch or guiding me towards a better solution, he went ahead and implemented his own fix, giving me credit only for reporting the issue […]

My first contribution to the [#Linux] #kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work. […]"

https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/

1/ Side note: I sometimes wonder if…

2/ Related: there is a proposal to discuss "trust and maintenance of [#Linux #kernel] file systems" on this years #LinuxKernel maintainer summit:

https://lore.kernel.org/all/ZO9NK0FchtYjOuIH@infradead.org/

"""we have a lot of on-disk file system drivers […] maintaining them is a burden, and there is a lot expectation on how they are maintained. […]

Part 2: unmaintained file systems

[…] The easiest way forward would be to remove everything that is not fully maintained, but that would remove a lot of useful features. […]"""

#Reiserfs in the #Linux mainline #kernel's MAINTAINERS file is now considered "Obsolete":

To quote https://git.kernel.org/torvalds/c/2363650b22ed3c8bbe7700789e399a77096ac931:

"""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

A bunch of new stable and longterm #Linux #kernel with mitigations for the #AMD #INCEPTION vulnerability aka CVE-2023-20569 and the #Intel #Downfall[2] vulnerability aka CVE-2022-40982 are now available on https://kernel.org.

@gregkh wrote: those fixes were "a pain to get done, odds are it will take a few more cycles and fixups once it hits real testing...". [3]

[1] https://fosstodon.org/@kernellogger/110855114931496454

[2] https://fosstodon.org/@kernellogger/110855362577587321

[3] https://social.kernel.org/objects/b82b2de0-6eca-44c3-99b4-68fc954a98fc

@jmorris

thx; hopefully it will help some people master this task when that would be helpful for bug reporting, debugging, and testing patches – at least that's why I wrote the text…

Paul McKenney's talk "So What Has RCU Done Lately?" from Everything Open is now online:

Recording: https://www.youtube.com/watch?v=9rNVyyPjoC4

Slides: https://drive.google.com/file/d/19Oa5phwRImKr4sUirjYxc8oOi0lKHxVL/view

Abstract: https://2023.everythingopen.au/schedule/presentation/46/

```[…] cover new features in the Linux kernel, primarily the polled RCU grace-period primitives that allow hardware interrupt handlers and even NMI handlers to interact with RCU grace periods. Other topics include new flavors of RCU for BPF and tracepoints […]```

#Linux #kernel #LinuxKernel