All posts by corbet

[$] A page-table isolation update

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

Dave Hansen did much of the work to get kernel page-table isolation
(PTI) into the kernel in response to the Meltdown CPU vulnerability. In the
memory-management track of the
2018 Linux Storage, Filesystem, and Memory-Management Summit, he ran a
discussion on how PTI came about, what the costs are, and what can be done
to minimize its performance impact.

[$] The impact of page-table isolation on I/O performance

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

Ever since kernel page-table isolation
(PTI)
was introduced as a mitigation for
the Meltdown CPU vulnerability, users have worried about how it affects the
performance of their systems. Most of that concern has been directed
toward its impact on computing performance, but I/O performance also
matters. At the 2018 Linux Storage, Filesystem, and Memory-Management
Summit, Ming Lei presented some preliminary work he has done to try to
quantify how severely PTI affects block I/O operations.

Vetter: Linux Kernel Maintainer Statistics

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

Daniel Vetter looks at
some kernel-development statistics
, with a focus on patches written by
the maintainers who commit them. “Naively extrapolating the relative trend predicts that around the year 2025 large numbers of kernel maintainers will do nothing else than be the bottleneck, preventing everyone else from getting their work merged and not contributing anything of their own. The kernel community imploding under its own bureaucratic weight being the likely outcome of that.

This is a huge contrast to the ‘everything is getting better, bigger, and
the kernel community is very healthy’ fanfare touted at keynotes and the
yearly kernel report. In my opinion, the kernel community is very much not
looking like it is coping with its growth well and an overall healthy
community.”

[$] Rewiring x86 system-call dispatch

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

Each kernel development cycle includes a vast number of changes that are
not intended to change visible behavior and which, as a result, go
unnoticed by most users and developers. One such change in 4.17 is a
rewiring of how system-call implementations are invoked within the kernel.
The change is interesting, though, and provides an opportunity to look at
the macro magic that handles system-call definitions.

[$] Rhashtables: under the hood

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

The first article in this series described
the interface to the “rhashtable”
resizable hash-table abstraction in Linux 4.15. While a knowledge of
the interface can result in successful use of rhashtables, it often
helps to understand what is going on “under the hood”, particularly when
those details leak out through the interface, as is occasionally the
case with rhashtable. The centerpiece for understanding the
implementation is knowing exactly how the table is resized. So this
follow-on article will explain that operation; it will also present the
configuration parameters that were skimmed over last time and discuss
how they affect the implementation.

[$] Finding Spectre vulnerabilities with smatch

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

The furor over the Meltdown and Spectre vulnerabilities has calmed a bit —
for now, at least — but that does not mean that developers have stopped
worrying about them. Spectre variant 1 (the bounds-check bypass
vulnerability) has been of particular concern because, while the kernel is
thought to contain numerous vulnerable spots, nobody really knows how to
find them all. As a result, the defenses that have been developed for
variant 1 have only been deployed in a few places. Recently, though,
Dan Carpenter has enhanced the smatch tool to enable it to find possibly
vulnerable code in the kernel.

[$] Zero-copy TCP receive

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

In the performance-conscious world of high-speed networking, anything that
can be done to avoid copying packet data is welcome. The MSG_ZEROCOPY feature added in 4.14
enables zero-copy transmission of data, but does not address the receive
side of the equation. It now appears that the 4.18 kernel will include a zero-copy receive mechanism by Eric Dumazet
to close that gap, at least for some relatively specialized applications.

[$] PostgreSQL’s fsync() surprise

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

Developers of database management systems are, by necessity, concerned
about getting data safely to persistent storage. So when the PostgreSQL
community found out that the way the kernel handles I/O errors could result
in data being lost without any errors being reported to user space, a fair
amount of unhappiness resulted. The problem, which is exacerbated by the
way PostgreSQL performs buffered I/O, turns out not to be unique to Linux,
and will not be easy to solve even there.

Introducing Microsoft Azure Sphere

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

Microsoft has issued a
press release
describing the security dangers involved with the
Internet of things (“a weaponized stove, baby monitors that spy, the
contents of your refrigerator being held for ransom
“) and introducing
“Microsoft Azure Sphere” as a combination of hardware and software to
address the problem. “Unlike the RTOSes common to MCUs today, our
defense-in-depth IoT OS offers multiple layers of security. It combines
security innovations pioneered in Windows, a security monitor, and a custom
Linux kernel to create a highly-secured software environment and a
trustworthy platform for new IoT experiences.

[$] The second half of the 4.17 merge window

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

By the time the 4.17 merge window was closed and 4.17-rc1 was
released, 11,769 non-merge changesets had been pulled into the
mainline repository. 4.17 thus looks to be a typically busy development
cycle, with a merge window only slightly more busy than 4.16 had.
Some 6,000 of those changes were pulled after last week’s summary was written. There was a
lot of the usual maintenance work in those patches (over 10% of those
changes were to device-tree files, for example), but also some more
significant changes.

Kernel prepatch 4.17-rc1

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

Linus has released 4.17-rc1 and closed the
merge window for this release. “This does not seem to be shaping up
to be a particularly big release, and there seems to be nothing
particularly special about it. The most special thing that happened is
purely numerology: we’ve passed the six million git objects mark, and that
is reason enough to call the next kernel 5.0. Except I probably won’t,
because I don’t want to be too predictable.

[$] The rhashtable documentation I wanted to read

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

The rhashtable data structure is a generic resizable hash-table
implementation in the Linux kernel, which LWN first introduced as “relativistic
hash tables” back in 2014. I thought at the time that it might be fun to make
use of rhashtables, but didn’t, until an opportunity arose through my work on
the Lustre filesystem. Lustre is a cluster filesystem that is currently in
drivers/staging while the code is revised to meet upstream
requirements. One of those requirements is to avoid duplicating
similar functionality where possible. As Lustre contains a resizable
hash table, it really needs to be converted to use rhashtables instead — at
last I have my opportunity.

Subscribers can read on for a look at the rhashtable API by guest author
Neil Brown.

Gettys: Mythology about security

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

Jim Gettys refutes
the claim
that the early designers of Internet software were not
concerned about security. “Government export controls crippled
Internet security and the design of Internet protocols from the very
beginning: we continue to pay the price to this day
“.

[$] Accelerating networking with AF_XDP

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

The Linux network stack does not lack for features; it also performs well
enough for most uses. At the highest network speeds, though, any overhead
at all is too much; that has driven the most demanding users toward
specialized, user-space networking implementations that can outperform the
kernel for highly constrained tasks. The express data path (XDP)
development effort is an attempt win those users back, with some apparent
success so far. With the posting of the AF_XDP patch set by Björn Töpel,
another piece of the XDP puzzle is coming into focus.