Search
85 results for “kernellogger”
-
#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:
https://lore.kernel.org/lkml/202409061[email protected]/
"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"
See also these earlier other related toots:
https://fosstodon.org/@kernellogger/113084762433941141
https://fosstodon.org/@kernellogger/113085326251565367 -
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
@kernellogger and use "journalctl -k -b-1" to see the Kernel messages of the previous boot.
Replace "-1" with any of the boot IDs provided by "journalctl --list-boots" (requires the journal to be configured as Storage=persistent in /etc/systemd/journald.conf)
-
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
Quick reminder in light of the recent #LinuxKernel vulnerabilities:
In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:
echo 1 | sudo tee /proc/sys/kernel/modules_disabled
Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄
More details on this:
* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German] -
Quick reminder in light of the recent #LinuxKernel vulnerabilities:
In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:
echo 1 | sudo tee /proc/sys/kernel/modules_disabled
Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄
More details on this:
* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German] -
Quick reminder in light of the recent #LinuxKernel vulnerabilities:
In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:
echo 1 | sudo tee /proc/sys/kernel/modules_disabled
Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄
More details on this:
* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German] -
RE: https://fedi.lwn.net/@lwn/116538328401421358
The patch to fix the second half of #DirtyFrag is at its third iteration now: https://lore.kernel.org/all/af2kdW2F1gJ9U-Gg@v4bel/
-
2/ for more details about the new autonomous self healing of filesystems in #xfs merged for Linux 7.0, see https://git.kernel.org/torvalds/c/04a65666a69508fa0022c7343026c5a3d41d166d
""This patchset builds new functionality to deliver live information about filesystem health events to userspace. This is done by creating an anonymous file that can be read() for events by userspace programs. Events are captured by hooking various parts of XFS and iomap so that metadata health failures, file I/O errors, and major changes in filesystem state (unmounts, shutdowns, etc.) can be observed by programs.
When an event occurs, the hook functions queue an event object to each event anonfd for later processing. Programs must have CAP_SYS_ADMIN to open the anonfd and there's a maximum event lag to prevent resource overconsumption. The events themselves can be read() from the anonfd as C structs for the xfs_healer daemon.
In userspace, we create a new daemon program that will read the event objects and initiate repairs automatically. This daemon is managed entirely by systemd and will not block unmounting of the filesystem unless repairs are ongoing. They are auto-started by a starter service that uses fanotify.""
-
Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:
https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4
""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]
The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.
Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""
-
Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:
https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4
""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]
The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.
Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""
-
Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:
https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4
""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]
The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.
Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""
-
Half of the support for the #initrd (not to be confused with #initramfs!) was removed from #Linux 7.0 through a #vfs merge from @brauner:
https://git.kernel.org/torvalds/c/996812c453cafa042f2e674738dbf8fa495661f3 and https://git.kernel.org/torvalds/c/ef12d0573a7f5e7a495e81d773ae5f3e98230cd4
""Remove the deprecated linuxrc-based initrd code path and related dead code. The linuxrc initrd path was deprecated in 2020 and this series completes its removal. If we see real-life regressions we'll revert. […]
The no-op load_ramdisk= and prompt_ramdisk= parameters are dropped, and noinitrd and ramdisk_start= gain deprecation warnings.
Initramfs is entirely unaffected. The non-linuxrc initrd path (root=/dev/ram0) is preserved but now carries a deprecation warning targeting January 2027 removal""
-
Highlights from the main #PowerManagement merge for #Linux 7.0:
""By the number of commits, cpufreq is the leading party (again) and the most visible change there is the removal of the omap-cpufreq driver that has not been used for a long time (good riddance). There are also quite a few changes in the cppc_cpufreq driver, mostly related to fixing its frequency invariance engine in the case […]
Next up is cpuidle and the changes there are dominated by intel_idle driver updates, mostly related to the new command line facility allowing users to adjust the list of C-states used by the driver. […]
The most significant update related to system suspend and hibernation is the one to stop freezing the PM runtime workqueue during system PM transitions which allows some deadlocks to be avoided. […]
[…]and there are assorted cleanups, documentation fixes, and some cpupower utility improvements. […]""
https://git.kernel.org/torvalds/c/9b1b3dcd28c271fc8c4a87e81860f3a34b6d29b7
-
Highlights from the main #PowerManagement merge for #Linux 7.0:
""By the number of commits, cpufreq is the leading party (again) and the most visible change there is the removal of the omap-cpufreq driver that has not been used for a long time (good riddance). There are also quite a few changes in the cppc_cpufreq driver, mostly related to fixing its frequency invariance engine in the case […]
Next up is cpuidle and the changes there are dominated by intel_idle driver updates, mostly related to the new command line facility allowing users to adjust the list of C-states used by the driver. […]
The most significant update related to system suspend and hibernation is the one to stop freezing the PM runtime workqueue during system PM transitions which allows some deadlocks to be avoided. […]
[…]and there are assorted cleanups, documentation fixes, and some cpupower utility improvements. […]""
https://git.kernel.org/torvalds/c/9b1b3dcd28c271fc8c4a87e81860f3a34b6d29b7
-
Highlights from the main #acpi merge for #Linux 7.0:
""This one is significantly larger than previous ACPI support pull requests because several significant updates have coincided in it.
First, there is a routine ACPICA code update, to upstream version 20251212, but this time it covers new ACPI 6.6 material that has not been covered yet. Among other things, it includes definitions of a few new ACPI tables and updates of some others, like the GICv5 MADT structures and ARM IORT IWB node definitions that are used for adding GICv5 ACPI probing on ARM (that technically is IRQ subsystem material, but it depends on the ACPICA changes, so it is included here). The latter alone adds a few hundred lines of new code.
Second, there is an update of ACPI _OSC handling including a fix that prevents failures from occurring in some corner cases due to careless handling of _OSC error bits.
On top of that, the "system resource" ACPI device objects with the PNP0C01 and PNP0C02 are now going to be handled by the ACPI core device enumeration code instead of handing them over to the legacy PNP system driver which causes device enumeration issues to occur. Some of those issues have been worked around in device drivers and elsewhere and those workarounds should not be necessary any more, so they are going away.
Moreover, the time has come to convert all "core ACPI" device drivers that were still using struct acpi_driver objects for device binding into proper platform drivers that use struct platform_driver for this purpose. These updates are accompanied by some requisite core ACPI device enumeration code changes.
Next, there are ACPI APEI updates, including changes to avoid excess overhead in the NMI handler and in SEA on the ARM side, changes to unify ACPI-based HW error tracing and logging, and changes to prevent APEI code from reaching out of its allocated memory.
There are also some ACPI power management updates, mostly related to the ACPI cpuidle support in the processor driver, suspend-to-idle handling on systems with ACPI support and to ACPI PM of devices.
In addition to the above, bugs are fixed and the code is cleaned up in assorted places all over.
[…] ""
https://git.kernel.org/torvalds/c/d84e173311c4f0b0300755e6445f3224d252eeed
-
Support for bounce buffering of DirectIO for stable pages was merged for #Linux 7.0 via @axboe
https://git.kernel.org/torvalds/c/4adc13ed7c281c16152a700e47b65d17de07321a
""This series tries to address the problem that under I/O pages can be modified during direct I/O, even when the device or file system require stable pages during I/O to calculate checksums, parity or data operations. It does so by adding block layer helpers to bounce buffer an iov_iter into a bio, then wires that up in iomap and ultimately XFS.
The reason that the file system even needs to know about it, is because reads need a user context to copy the data back, and the infrastructure to defer ioends to a workqueue currently sits in #XFS. I'm going to look into moving that into ioend and enabling it for other file systems. Additionally #btrfs already has it's own infrastructure for this, and actually an urgent need to bounce buffer, so this should be useful there and could be wire up easily. In fact the idea comes from patches by Qu that did this in btrfs. […]""
-
#io_uring #bpf filter support was merged for #Linux 7.0 by @axboe
https://git.kernel.org/torvalds/c/591beb0e3a03258ef9c01893a5209845799a7c33 [update] see also: https://lwn.net/Articles/1054225/ and for the liburing side (which has both man pages and an extensive test case that also demonstrate how to use it) https://git.kernel.org/pub/scm/linux/kernel/git/axboe/liburing.git/commit/ [/update]
""This adds support for both cBPF filters for io_uring, as well as task inherited restrictions and filters. […]
seccomp and io_uring don't play along nicely, […] As a result, things like containers and systemd that apply seccomp filters, can't filter io_uring operations.
That leaves them with just one choice if filtering is critical - filter the actual io_uring_setup(2) system call to simply disallow io_uring. That's rather unfortunate, and has limited us because of it.
io_uring already has some filtering support. […] This first adds support for cBPF filters for opcodes, which enables tighter control over what exactly a specific opcode may do. […] These filters are run post the init phase of the request […] On top of that support is added for per-task filters , meaning that any ring created with a task that has a per-task filter will get those filters applied when it's created.[…]""
-
Highlights from the main #xfs merge for #Linux 7.0:
https://git.kernel.org/torvalds/c/56feb532bb927ae1c26726e2e7c0de95f54a3d67
""This contains several improvements to zoned device support, performance improvements for the parent pointers, and a new health monitoring feature [for more about the latter, see https://lwn.net/Articles/1055062/].""
-
#VFS support for generic I/O error reporting was merged for #Linux 7.0 by @brauner
https://git.kernel.org/torvalds/c/dd466ea0029961ee0ee6e8e468faa1506275c8a9
""Filesystems currently have no standard mechanism for reporting metadata corruption and file I/O errors to userspace via fsnotify. Each filesystem (xfs, ext4, erofs, f2fs, etc.) privately defines EFSCORRUPTED, and error reporting to fanotify is inconsistent or absent entirely.
This introduces a generic fserror infrastructure built around struct super_block that gives filesystems a standard way to queue metadata and file I/O error reports for delivery to fsnotify.
Errors are queued via mempools and queue_work to avoid holding filesystem locks in the notification path; unmount waits for pending events to drain. A new super_operations::report_error callback lets filesystem drivers respond to file I/O errors themselves (to be used by an upcoming XFS self-healing patchset).
On the uapi side, EFSCORRUPTED and EUCLEAN are promoted from private per-filesystem definitions to canonical errno.h values across all architectures""
-
#VFS support for generic I/O error reporting was merged for #Linux 7.0 by @brauner
https://git.kernel.org/torvalds/c/dd466ea0029961ee0ee6e8e468faa1506275c8a9
""Filesystems currently have no standard mechanism for reporting metadata corruption and file I/O errors to userspace via fsnotify. Each filesystem (xfs, ext4, erofs, f2fs, etc.) privately defines EFSCORRUPTED, and error reporting to fanotify is inconsistent or absent entirely.
This introduces a generic fserror infrastructure built around struct super_block that gives filesystems a standard way to queue metadata and file I/O error reports for delivery to fsnotify.
Errors are queued via mempools and queue_work to avoid holding filesystem locks in the notification path; unmount waits for pending events to drain. A new super_operations::report_error callback lets filesystem drivers respond to file I/O errors themselves (to be used by an upcoming XFS self-healing patchset).
On the uapi side, EFSCORRUPTED and EUCLEAN are promoted from private per-filesystem definitions to canonical errno.h values across all architectures""