All posts by corbet

[$] TCP small queues and WiFi aggregation — a war story

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

This article describes our findings that connected TCP small queues (TSQ)
with the behavior of advanced WiFi protocols and, in the process, solved a
throughput
regression. The resulting patch is already in the mainline tree, so before
continuing,
please make sure your kernel is updated. Beyond the fix, it is
delightful to travel through history to see how we discovered the problem,
how it was tackled, and how it was patched.

Subscribers can read on for the full story by guest authors Carlo Grazia and Natale Patriciello.

[$] 4.18 Merge window, part 2

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

By the time that Linus Torvalds released 4.18-rc1 and closed the merge
window for this development cycle, 11,594 non-merge changesets had
found their way into the mainline kernel repository. Nearly 4,500 of those
were pulled after last week’s summary was
written. Thus, in terms of commit traffic, 4.18 looks to be quite similar
to its predecessors. As usual, the entry of significant new features has
slowed toward the end of the merge window, but there are still some
important changes on the list.

[$] Toward a fully reproducible Debian

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

It’s been a little over one year since we last covered Debian’s reproducible builds
project. The effort has not stopped in the interim; progress continues
to be made, the message has sharpened up, and word is spreading. Chris
Lamb, speaking about this at FLOSS UK in a talk called “You may think
you’re not a target: a tale of three
developers”, hinted that the end may be starting to come into sight.

Cook: security things in Linux v4.17

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

Kees Cook describes
the security-oriented changes included in the 4.17 kernel release.
“It was possible that old memory contents would live in a new
process’s kernel stack. While normally not visible, “uninitialized” memory
read flaws or read overflows could expose these contents (especially stuff
“deeper” in the stack that may never get overwritten for the life of the
process). To avoid this, I made sure that new stacks were always
zeroed. Oddly, this “priming” of the cache appeared to actually improve
performance, though it was mostly in the noise.”

Backdoored images downloaded 5 million times finally removed from Docker Hub (ars technica)

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

Ars technica has the
story of a set of Docker images containing cryptocurrency miners that
persisted on Docker Hub for the better part of a year — after being
discovered. “Neither the
Docker Hub account nor the malicious images it submitted were taken
down. Over the coming months, the account went on to submit 14 more
malicious images. The submissions were publicly called out two more times,
once in January by security firm Sysdig and again in May by security
company Fortinet. Eight days after last month’s report, Docker Hub finally
removed the images.”

[$] Heterogeneous memory management meets EXPORT_SYMBOL_GPL()

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

One of the many longstanding — though unwritten — rules of kernel
development is that infrastructure is not merged until at least one user
for that infrastructure exists. That helps developers evaluate potential
interfaces and be sure that the proposed addition is truly needed. A big
exception to this rule was made when the heterogeneous memory management
(HMM) code was merged, though. One of the reasons for the lack of users in
this case turns out to be that many of the use cases are proprietary; that
has led to some disagreements over the GPL-only status of an exported
kernel symbol.

Trouble at CopperheadOS

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

LWN reviewed CopperheadOS, a
security-enhanced Android distribution, in 2016. Unfortunately, the
company behind CopperheadOS appears to have run into internal trouble; we
don’t dare venture a guess as to the specifics, even after watching the
situation for a few days, beyond the fact that there
is clearly a dispute between the founders. This
Reddit post is apparently a letter to co-founder Daniel Micay
essentially kicking him out of the company. Users of CopperheadOS may want
to be considering alternatives.

[$] Year-2038 work in 4.18

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

We now have less than 20 years to wait until the time_t value used
on 32-bit systems will overflow and create time-related mayhem across the
planet. The grand plan for solving this
problem was posted over three years ago now; progress since then has
seemed slow. But quite a bit of work has happened deep inside the kernel
and, in 4.18, some of the first work that will be visible to user space has
been merged. The year-2038 problem is not yet solved, but things are
moving in that direction.

One year of postmarketOS

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

Here’s a
detailed update from the postmarketOS project on its first year.
PostmarketOS is building an Android distribution aimed at keeping older
devices working in a supported mode; much of this work involves getting
mainline kernels working on various handsets.
“You might remember @bshah’s photo of the Nexus 5 running mainline
with a flipped and distorted screen from December. @flto continued his
work: the display works without problems now. But it gets even better: the
touch screen is working, 3D acceleration is enabled with the open source
freedreno userspace driver, Wi-Fi works, and the best part is that
@MartijnBraam was able to send SMS and initialize a call via command line
as well as getting the connectivity signal from the modem through oFono
displayed in Plasma Mobile (#1502). All of that without proprietary
userspace blobs!”

Hutterer: Observations on trackpoint input data

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

Peter Hutterer writes
about the behavior of trackpoint devices in great detail.
“Trackpoints have built-in calibration procedures to find and set
their own center-point. Without that you’ll get the trackpoint eventually
being ever so slightly off center over time, causing a mouse pointer that
just wanders off the screen, possibly into the woods, without the
obligatory red cape and basket full of whatever grandma eats when she’s
sick.”

[$] Will staging lose its Lustre?

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

The kernel’s staging tree is meant to be a path by which substandard code
can attract increased developer attention, be improved, and eventually find
its way into the mainline kernel. Not every module graduates from
staging; some are simply removed after it becomes clear that nobody cares
about them. It is rare, though, for a project that is actively developed
and widely used to be removed from the staging tree, but that may be about
to happen with the Lustre filesystem.