On April 21, Andrew Morton let
it be known that he intends to begin stepping away from the
maintainership of kernel’s memory-management subsystem — a responsibility
he has carried since before memory management was even seen as its own
subsystem. At the 2026 Linux Storage, Filesystem, Memory Management, and
BPF Summit, one of the first sessions in the memory-management track was
devoted to how the maintainership would be managed going forward. There
are a lot of questions still to be answered.
The PHP project has long shipped under its own license — except for
the parts under the Zend Engine License. The PHP project has now announced
that the PHP license has been retired, and the PHP code has been relicensed
under the three-clause BSD license. See this
blog entry for more details.
Getting here required more than writing an
RFC. The PHP License gives the PHP Group the authority to
change it, which meant tracking down each of the original PHP Group
members and getting their written consent. Each approved the
proposal. Perforce Software, the successor to Zend Technologies,
needed to sign off on the Zend Engine side, as well. They provided
a formal letter confirming their full authority and support for the
change. I hired an attorney to review the proposal and provide
advice on any legal questions that might surface during the
discussion period. Speaking of which, I allowed for a six-month
community discussion period preceding the vote, which passed
unanimously.
The second 7.1 kernel prepatch is out for
testing. “It’s not small, and while it’s a bit early to say for sure, I
do suspect we’re seeing the same continued pattern of more patches than
usual – probably due to AI tooling – that we saw in 7.0.“
Hyrum’s Law states that any
observable behavior of a system will eventually be depended upon by
somebody. The kernel community is currently contending with a clear
demonstration of that principle. The recent work to address some restartable-sequences
performance problems in the 6.19 release maintained the documented API
in all respects, but that was not enough; Google’s TCMalloc
library, as it turns out, violates the documented API, prevents other code
from using restartable features, and breaks with 6.19. But the kernel’s
no-regressions rule is forcing developers to find a way to accommodate
TCMalloc’s behavior.
By the time Linus Torvalds released 7.1-rc1
and closed the 7.1 merge window, 12,996 non-merge changesets had been
pulled into the mainline repository; just over 9,000 of those arrived after the first-half summary was written. These
changes were more driver-oriented than those seen earlier, but still also
included many new features across the kernel as a whole.
Linus has released 7.1-rc1 and closed the
merge window for this release.
Things look fairly normal, although we do have a few different
projects to cull some old hardware support to help minimize
maintenance burden: phasing out i486 support (configs deleted, code
deletions to follow) and independently starting to remove some
really old networking hardware support, and removing some SoC
support that never went anywhere.
But we’re more than making up for any stale code removal with all
the new features and code added, so the diffstat still shows many
more lines added than removed.
The kernel coverage here at LWN often touches on memory-management topics
and, as a result, tends to talk a lot about both pages and folios. As the
folio transition in the kernel has moved forward, it has often become
difficult to decide which term to use in writing that is meant to be both
approachable and technically correct. As this work continues, it will be
increasingly common to use “folio” rather than page. This article is
intended to be a convenient reference for readers wanting to differentiate
the two terms or understand the state of this transition.
The famfs filesystem first showed up on the
mailing lists in early 2024; since then, it has been the topic of
regular discussions at the Linux Storage, Filesystem, Memory Management and
BPF (LSFMM+BPF) Summit. It has also, as result of those discussions, been
through some significant changes since that initial posting. So it is not
surprising that a suggestion that it needed to be rewritten yet again was
not entirely well received. How much more rewriting will actually be
needed is unclear, but more discussion appears certain.
Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol
implementation and all associated hamradio device drivers from the
kernel tree. This set of protocols has long been a huge bug/syzbot
magnet, and since nobody stepped up to help us deal with the influx
of the AI-generated bug reports we need to move it out of tree to
protect our sanity.
This
Firefox blog post reports that the Firefox 150 release includes
fixes for 271 vulnerabilities found by the Claude Mythos preview.
Elite security researchers find bugs that fuzzers can’t largely by
reasoning through the source code. This is effective, but
time-consuming and bottlenecked on scarce human
expertise. Computers were completely incapable of doing this a few
months ago, and now they excel at it. We have many years of
experience picking apart the work of the world’s best security
researchers, and Mythos Preview is every bit as capable. So far
we’ve found no category or complexity of vulnerability that humans
can find that this model can’t.
This can feel terrifying in the immediate term, but it’s ultimately
great news for defenders. A gap between machine-discoverable and
human-discoverable bugs favors the attacker, who can concentrate
many months of costly human effort to find a single bug. Closing
this gap erodes the attacker’s long-term advantage by making all
discoveries cheap.
One of the more significant changes in the 7.0 kernel release is to use the lazy-preemption mode by default in the CPU
scheduler. The scheduler developers have wanted to reduce the number of
preemption modes for years, and lazy preemption looks like a step toward
that goal. But then there came this report
from Salvatore Dipietro that lazy preemption caused a 50% performance
regression on a PostgreSQL benchmark. Investigation showed that the
situation is not actually so grave, but the episode highlights just how
sensitive some workloads can be to configuration changes; there may be
surprises in store for other users as well.
The 7.1 merge window opened on April 12 with the release
of the 7.0 kernel. Since then, 3,855 non-merge changesets have been
pulled into the mainline repository for the next release. This merge
window is thus just getting started, but there has still been a fair amount
of interesting work moving into the mainline.
Version 4.0.0 of the OpenSSL cryptographic library has been released. This
release includes support for a number of new cryptographic algorithms and
has a number of incompatible changes as well; see the announcement for the
details.
Linus Torvalds released the 7.0 kernel as
expected on April 12, ending a relatively busy development cycle. The
7.0 release brings a large number of interesting changes; see the LWN
merge-window summaries (part 1, part 2) for all the details. Here,
instead, comes our traditional look at where those changes came from and
who supported that work.
Linus has released the 7.0 kernel after a
busy nine-week development cycle.
The last week of the release continued the same “lots of small
fixes” trend, but it all really does seem pretty benign, so I’ve
tagged the final 7.0 and pushed it out.
I suspect it’s a lot of AI tool use that will keep finding corner
cases for us for a while, so this may be the “new normal” at least
for a while. Only time will tell.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.