All posts by corbet

LWN emails bouncing due to dnsbl.njabl.org

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

There are currently a number of sites bouncing emails from LWN.net due to an
alleged listing in the dnsbl.njabl.org blacklist. The only problem is that
this blacklist has
been offline since 2013
. That domain has been taken over by somebody
else; checking web content at that address is not recommended as it is, to
put it lightly, non-technical. If you are not getting expected email from
LWN, you might want to look into whether your local setup is still trying
to use that old, discontinued blacklist.

Cuni: PyPy for low-latency systems

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

Antonio Cuni writes
about recent work
to support running Python code with low latency
requirements under PyPy. “As we said, the total cost of memory
management is less on PyPy than on CPython, and it’s one of the reasons why
PyPy is so fast. However, one big disadvantage is that while on CPython the
cost of memory management is spread all over the execution of the program,
on PyPy it is concentrated into GC runs, causing observable pauses which
interrupt the execution of the user program. To avoid excessively long
pauses, the PyPy GC has been using an incremental strategy since 2013. The
GC runs as a series of ‘steps’, letting the user program to progress
between each step.

[$] Some unreliable predictions for 2019

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

The January 3 LWN.net Weekly Edition will be our first for 2019, marking
our return after an all-too-short holiday period. Years ago, we made the
ill-considered decision to post some predictions at the beginning of the
year and, like many mistakes, that decision has persisted and become an
annual tradition. We fully expect 2019 to be an event-filled year, with
both ups and downs; read on for some wild guesses as to what some of those
events may look like.

[$] What’s coming in the next kernel release (part 1)

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

When the 4.20 kernel was released on
December 23, Linus Torvalds indicated that he would try to keep to the
normal merge window schedule despite the presence of the holidays in the
middle of it. Thus far, he seems to be trying to live up to that;
just over 8,700 changesets have been merged for the next release, which
seems likely to be called 5.0. A number of long-awaited features are
finally landing in the kernel with this release.

[$] Improving idle behavior in tickless systems

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

Most processors spend a great deal of their time doing nothing, waiting
for devices and timer interrupts. In these cases, they can switch to idle
modes that shut down parts of their internal circuitry, especially stopping
certain clocks. This lowers power consumption significantly
and avoids draining device batteries. There are usually
a number of idle modes available; the deeper the mode is, the less power the
processor needs. The tradeoff is that the cost of switching to and from
deeper modes is
higher; it takes more time and the content of some caches is also lost. In the
Linux kernel, the cpuidle subsystem has the task of predicting which choice
will be the most appropriate. Recently, Rafael Wysocki proposed
a new governor
for systems with tickless operation enabled that is
expected to be more accurate than the existing menu governor.

Cook: Security things in Linux v4.20

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

Kees Cook summarizes
the security-related improvements
in the 4.20 kernel.
Enabling CONFIG_GCC_PLUGIN_STACKLEAK=y means almost all
uninitialized variable flaws go away, with only a very minor performance
hit (it appears to be under 1% for most workloads). It’s still possible
that, within a single syscall, a later buggy function call could use
‘uninitialized’ bytes from the stack from an earlier function. Fixing this
will need compiler support for pre-initialization (this is under
development already for Clang, for example), but that may have larger
performance implications.

The 4.20 kernel has been released

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

Linus has released 4.20 as expected.
Let’s face it, last week wasn’t quite as quiet as I would have hoped
for, but there really doesn’t seem to be any point to delay 4.20
because everybody is already taking a break.
” Some of the headline
features in 4.20 include
network flow dissectors in BPF,
the taprio
traffic scheduler
,
peer-to-peer DMA support in the PCI layer,
C-SKY architecture support,
the pressure-stall instrumentation mechanism,
the XArray data structure,
and much more. The KernelNewbies 4.20 page is
coming together with more information.

[$] Some 4.20 development statistics

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

This year’s holiday gifts will include the 4.20 kernel; that can only mean
that it is time for another look at where the code going into this release
has come from. This development cycle was typically busy and brought a lot
of new code into the kernel. There are some new faces showing up in the
statistics this time around, but not a lot of surprises otherwise.

[$] Live patching for CPU vulnerabilities

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

The kernel’s live-patching (KLP) mechanism can apply a wide variety of
fixes to a running kernel but, at a first glance, the sort of highly
intrusive changes needed to address vulnerabilities like Meltdown or L1TF
would not seem like likely candidates for live patches.
The most notable obstacles are the required
modifications of global semantics on a running system, as well as the
need for live patching the kernel’s entry code. However, we at the SUSE live
patching team started working on proof-of-concept live patches for these
vulnerabilities as a
fun project and have been able to overcome these hurdles. The
techniques we developed are generic and might become handy again when
fixing future vulnerabilities.

[$] A 2018 retrospective

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

The December 20 LWN.net Weekly Edition is the final one for the year; as
usual, we will be taking the last week of the year off for a brief rest.
LWN, which is about to conclude its 21st year of publication, has had the
time to build up some traditions, one of which is a year-end retrospective
that evaluates the predictions we made back
in January. As usual, some of those predictions aged rather better than
others; read on for our report card.

[$] Relief for retpoline pain

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

Indirect function calls — calls to a function whose address is stored in a
pointer variable — have never been blindingly fast, but the Spectre
hardware vulnerabilities have made things far worse. The indirect branch
predictor used to speed up indirect calls in the CPU can no longer be
used, and performance has suffered accordingly. The “retpoline”
mechanism

was a brilliant hack that proved faster than the hardware-based solutions
that were tried at the beginning. While retpolines took a lot of the pain
out of Spectre mitigation, experience over the last year has made it clear
that they still hurt. It is thus not surprising that developers have been
looking for alternatives to retpolines; several of them have shown up on
the kernel lists recently.

[$] Linux in mixed-criticality systems

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

The Linux kernel is generally seen as a poor fit for safety-critical
systems; it was never designed to provide realtime response guarantees or
to be certifiable for such uses. But the systems that can be used
in such settings lack the features needed to support complex applications.
This problem is often solved by deploying a mix of computers running
different operating systems. But what if you want to support a mixture of
tasks, some safety-critical and some not, on the same system? At a talk
given at LinuxLab 2018, Claudio
Scordino described an effort to support this type of mixed-criticality
system.

The x32 subarchitecture may be removed

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

The x32 subarchitecture
is a software variant of x86-64; it runs the processor in the 64-bit mode,
but uses 32-bit pointers and arithmetic. The idea is to get the advantages
of x86-64 without the extra memory usage that goes along with it. It
seems, though, that x32 is not much appreciated; few distributions support
it and the number of users appears to be small. So now Andy Lutomirski is
proposing
its eventual removal
:

I propose that we make CONFIG_X86_X32 depend on BROKEN for a release
or two and then remove all the code if no one complains. If anyone
wants to re-add it, IMO they’re welcome to do so, but they need to do
it in a way that is maintainable.

If there are x32 users out there, now would be a good time for them to
speak up.