Hírolvasó

[$] Development statistics for the 6.15 kernel

1 hónap 1 hét óta
The 6.14 kernel development cycle only brought in 11,003 non-merge changesets, making it the slowest cycle since 4.0, which was released in 2015. The 6.15 kernel, instead, brought in 14,612 changesets, making it the busiest release since 6.7, released at the beginning of 2024. The kernel development process, in other words, is back up to full speed. The 6.15 release happened on May 25, so the time has come for the obligatory look at where the changes in this release came from.
corbet

Security updates for Monday

1 hónap 1 hét óta
Security updates have been issued by AlmaLinux (389-ds-base, ghostscript, grafana, kernel, and osbuild-composer), Debian (intel-microcode, kernel, libphp-adodb, and openssl), Fedora (dotnet8.0, ghostscript, iputils, nbdkit, open-vm-tools, thunderbird, and vyper), Mageia (chromium-browser-stable, glibc, iputils, microcode, nodejs, and zsync), Oracle (.NET 8.0, .NET 9.0, 389-ds-base, avahi, buildah, compat-openssl11, expat, firefox, ghostscript, gimp, git, grafana, gvisor-tap-vsock, libsoup, libxslt, mod_auth_openidc, nginx, nodejs:20, osbuild-composer, podman, skopeo, thunderbird, vim, webkit2gtk3, xdg-utils, xterm, and yelp), Red Hat (kernel, kernel-rt, libsoup, libsoup3, python-tornado, and ruby), Slackware (ffmpeg), SUSE (audiofile, firefox, glibc, govulncheck-vulndb, grafana, kernel, kind, kubo, libecpg6, postgresql13, postgresql14, python-Django, python-setuptools, python-tornado6, python311-Flask, python311-tornado6, python313, python36-setuptools, thunderbird, transfig, and xen), and Ubuntu (glib2.0, linux-bluefield, linux-ibm, linux-raspi, and openjdk-21-crac).
jake

The 6.15 kernel has been released

1 hónap 1 hét óta
Linus has released the 6.15 kernel, as expected.

So this was delayed by a couple of hours because of a last-minute bug report resulting in one new feature being disabled at the eleventh hour, but 6.15 is out there now.

Significant changes in 6.15 include smarter timer-ID assignment to make checkpoint/restore operations more reliable, the ability to read status information from a pidfd after the process in question has been reaped, the PIDFD_SELF special pidfd value, nested ID-mapped mounts, zero-copy network-data reception via io_uring, The ability to read epoll events via io_uring, resilient queued spinlocks for BPF programs, guard-page enhancements allowing them to be placed in file-backed memory areas and for user space to detect their presence, the once-controversial fwctl subsystem, the optional sealing of some system mappings, and much more.

See the LWN merge-window summaries (part 1, part 2) and the in-progress KernelNewbies 6.15 page for more information.

corbet

New profiling subsystem committed to -current

1 hónap 1 hét óta
A new profiling subsystem is now in OpenBSD-current, from the hands of none other than Theo de Raadt (deraadt@) himself.

A longish sequence of commits introduced the changes incrementally, with a summary as follows: List: openbsd-cvs Subject: CVS: cvs.openbsd.org: src From: Theo de Raadt <deraadt () cvs ! openbsd ! org> Date: 2025-05-24 6:49:17 CVSROOT: /cvs Module name: src Changes by: deraadt@cvs.openbsd.org 2025/05/24 00:49:17 Modified files: include : unistd.h sys/sys : exec.h exec_elf.h gmon.h proc.h systm.h sys/kern : exec_elf.c init_sysent.c kern_exec.c kern_exit.c kern_fork.c kern_pledge.c subr_prof.c syscalls.master Log message: In the old gprof profiling subsystem, the simplistic profil() syscall told the kernel about the sample buffer, and then the normal exit-time _mcleanup() would finalize the buffer, open()'ed a file and write out the details. This file opening has become increasingly impossible because of our privsep / privdrop, chroot, setresuid uid-dropping, pledge, unveil, and other efforts. So people stopped using gprof. Programs which needed profiling needed substantial mitigation removal changes to put them under test.

Read more…