All posts by corbet

[$] Controlling device peer-to-peer access from user space

Post Syndicated from corbet original https://lwn.net/Articles/782489/rss

The recent addition of
support for direct (peer-to-peer) operations between PCIe devices
in the
kernel has opened the door for different use cases. The initial work
concentrated on in-kernel support and the NVMe subsystem; it also
added support for memory regions that can be used for such transfers.
Jérôme Glisse recently proposed
two extensions
that would allow the mapping of those regions into user
space and mapping device files between two devices.
The resulting discussion surprisingly led to consideration of the
future of core kernel structures dealing with memory management.

[$] Two topics in user-space access

Post Syndicated from corbet original https://lwn.net/Articles/781283/rss

Kernel code must often access data that is stored in user space. Most of
the time, this access is uneventful, but it is not without its dangers and
cannot be done without exercising due care. A couple of recent discussions
have made it clear that this care is not always being taken, and that not
all kernel developers fully understand how user-space access should be
performed. The good news is that kernel developers are currently working
on a set of changes to make user-space access safer in the future.

Rosenzweig: The federation fallacy

Post Syndicated from corbet original https://lwn.net/Articles/781205/rss

Here’s a
lengthy piece from Alyssa Rosenzweig
on preserving freedom despite the
inevitable centralization of successful information services.
Indeed, it seems all networked systems tend towards centralisation
as the natural consequence of growth. Some systems, both legitimate and
illegitimate, are intentionally designed for centralisation. Other systems,
like those in the Mastodon universe, are specifically designed to avoid
centralisation, but even these succumb to the centralised black hole as
their user bases grow towards the event horizon.

The 5.0 kernel has been released.

Post Syndicated from corbet original https://lwn.net/Articles/780640/rss

Linus has released the 5.0 kernel.
But I’d
like to point out (yet again) that we don’t do feature-based releases,
and that “5.0” doesn’t mean anything more than that the 4.x numbers
started getting big enough that I ran out of fingers and toes.

Headline features from this release include
the energy-aware
scheduling
patch set,
a bunch of year-2038 work that comes close
to completing the core-kernel transition,
zero-copy networking for UDP traffic,
the Adiantum encryption algorithm,
the seccomp trap to user space mechanism,
and, of course, lots of new drivers and fixes.
See the KernelNewbies 5.0
page
for lots of details.

[$] A kernel unit-testing framework

Post Syndicated from corbet original https://lwn.net/Articles/780985/rss

For much of its history, the kernel has had little in the way of formal
testing infrastructure. It is not entirely an exaggeration to say that
testing is what the kernel community kept users around for. Over the
years, though, that situation has improved; internal features like
kselftest and services like the 0day testing system have increased our test
coverage considerably. The story is unlikely to end there, though; the
next addition to the kernel’s testing arsenal may be a unit-testing framework
called KUnit.

[$] Core scheduling

Post Syndicated from corbet original https://lwn.net/Articles/780703/rss

Kernel developers are used to having to defend their work when posting it
to the mailing lists, so when a longtime kernel developer describes their
own work as
expensive and nasty“, one tends to wonder what
is going on. The patch set in question is core
scheduling
from Peter Zijlstra. It is intended to make simultaneous
multithreading (SMT) usable on systems where cache-based side channels are
a concern, but even its author is far from convinced that it should
actually become part of the kernel.

[$] Memory-mapped I/O without mysterious macros

Post Syndicated from corbet original https://lwn.net/Articles/780710/rss

Concurrency is hard even when the hardware’s behavior is entirely
deterministic; it gets harder in situations where operations can be
reordered in seemingly random ways. In these cases, developers tend to
reach for barriers as a way of enforcing ordering, but explicit barriers
are tricky to use and are often not the best way to think about the
problem. It is thus common to see explicit barriers removed as code
matures. That now seems to be happening with an especially obscure
type of barrier used with memory-mapped I/O (MMIO) operations.

Kernel prepatch 5.0-rc8

Post Syndicated from corbet original https://lwn.net/Articles/780645/rss

Anybody expecting the 5.0 kernel to come out today will have been
disappointed; Linus released 5.0-rc8
instead. “This may be totally unnecessary, but we actually had more
patches come in this last week than we had for rc7, which just didn’t make
me feel the warm and fuzzies. And while none of the patches looked all that
scary, some of them were to pretty core files, so it wasn’t all just random
rare drivers (although those kinds also existed).

[$] Containers as kernel objects — again

Post Syndicated from corbet original https://lwn.net/Articles/780364/rss

Linus Torvalds once famously said
that there is no design behind the Linux kernel. That may be true, but
there are still some guiding principles behind the evolution of the kernel;
one of those, to date, has been that the kernel does not recognize
“containers” as objects in their own right. Instead, the kernel provides
the necessary low-level features, such as namespaces and control groups, to
allow user space to create its own container abstraction. This refusal to
dictate the nature of containers has led to a diverse variety of container
models and a lot of experimentation. But that doesn’t stop those who would
still like to see the kernel recognize containers as first-class
kernel-supported objects.

[$] Development statistics for the 5.0 kernel

Post Syndicated from corbet original https://lwn.net/Articles/780271/rss

The announcement of the 5.0-rc7 kernel
prepatch on February 17 signaled the imminent release of the final 5.0
kernel and the end of this development cycle. 5.0, as it turns out,
brought in fewer changesets than its immediate predecessors, but it was
still a busy cycle with a lot of developers participating. Read on for an
overview of where the work came from in this release cycle.

[$] The case of the supersized shebang

Post Syndicated from corbet original https://lwn.net/Articles/779997/rss

Regressions are an unavoidable side effect of software development; the
kernel is no different in that regard. The 5.0 kernel introduced a change
in the handling of the “#!” (or “shebang”) lines used to indicate
which interpreter should handle an executable text file. The problem has
been duly fixed, but the incident shows how easy it can be to introduce
unexpected problems and highlights some areas where the kernel’s
development process does not work as well as we might like.

Geary 0.13.0 released

Post Syndicated from corbet original https://lwn.net/Articles/780003/rss

Version 0.13.0 of the Geary graphical email client is out.
This is a major new release, featuring a number of new features —
including a new user interface for creating and managing email
accounts, integration with GNOME Online Accounts (which also provides
OAuth login support for some services), improvements in displaying
conversations, composing new messages, interacting with other email
apps, reporting problems as they occur, and number of important bug
fixes, server compatibility fixes, and security fixes.

[$] Per-vector software-interrupt masking

Post Syndicated from corbet original https://lwn.net/Articles/779738/rss

Software interrupts (or “softirqs”) are one of the oldest
deferred-execution mechanisms in the kernel, and that age shows at times.
Some developers have occasionally been heard to mutter about removing them, but
softirqs are too deeply embedded into how the kernel works to be easily ripped
out; most developers just leave them alone. So the recent per-vector
softirq masking patch set
from Frederic Weisbecker is noteworthy as an
exception to that rule. Weisbecker is not getting rid of softirqs, but he
is trying to reduce their impact and improve their latency.