All posts by corbet

[$] The intersection of mlx5, netdev, and lockdown

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

The NVIDIA Mellanox ConnectX HW family of adapters is a complex beast,
supporting networking, InfiniBand, RDMA, and more. As a result, the mlx5
kernel driver that supports this hardware is also complex, as is the
interface that it provides to user space. The mlx5 developers have, for a
while now, been proposing
the addition of a new control interface, in the form of a separate virtual
device exported by the kernel, that would make vast amounts of debugging
information available. This driver has encountered some significant
opposition on its way toward the mainline, though, raising a number of
questions about appropriate interfaces and when subsystem maintainers have
veto power over submissions.

Min: sched_ext: a BPF-extensible scheduler class (Part 1)

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

Changwoo Min provides
an introduction to the sched_ext scheduling class
:

Sched_ext was proposed to address the problems mentioned above. It
allows users to write a custom scheduling policy using BPF without
modifying the kernel code. You don’t need to struggle to maintain
the out-of-tree custom scheduler. In addition, BPF provides a safe
kernel programming environment. In particular, the BPF verifier
ensures that your custom scheduler has neither a memory bug nor an
infinite loop. Also, if your custom scheduler misbehaves — like
failing to schedule a task for too long (say 30 seconds), the
kernel portion of sched_ext kills your custom scheduler and falls
back to the default kernel scheduler (CFS or EEVDF). Last but not
least, you can update the BPF scheduler without reinstalling the
kernel and rebooting a server.

(LWN looked at sched_ext in February 2023).

DeMaio: Insights from the openSUSE Logo Contest

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

In response to the expressed unhappiness over the recent logo-selection
process in the openSUSE project (covered in this article), the project has announced
that there will be a new vote:

During the community meeting this week where the results were
discussed, participants expressed the view that members of the
openSUSE Project have an opportunity to participate in the
selection of our new logo, and that SUSE, which holds the trademark
to the openSUSE logo, be involved with the process for selecting a
branding decision with regard to the results. After all, this
decision impacts the collective identity.

To facilitate this, there is a plan to organize a vote between the
current logo and the proposed new design, allowing our community to
have a say in this important decision. Furthermore, members of the
project are collaborating with SUSE on the implications of the
branding initiatives and some have expressed the desire for SUSE’s
input to ensure there is an aligned vision for the future of
openSUSE.

[$] Progress toward a GCC-based Rust compiler

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

The gccrs project is an ambitious
effort started in 2014 to implement a Rust compiler within The GNU Compiler
Collection (GCC). Even though the task is far from complete, progress has
been made since LWN’s previous coverage,
according to reports from the project. Meanwhile, another hybrid and more
mature approach to GCC Rust code generation is available in rust_codegen_gcc.

[$] Ext4 data corruption hits the stable kernels

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

The kernel’s stable-update process is intended to produce kernels that are,
well, stable; when that promise is lived up to, users can update to newer
stable updates without fear. By any account, a bug that corrupts data on
ext4 filesystems constitutes a failure to hold to that promise. As is so
often the case, this problem is the result of a chain of failures in a
system that works well most of the time.

Rust for Linux — in space

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

The Rust for Linux (RFL) project may not have (yet) resulted in user-visible
changes to the Linux kernel, but it seems the wider world has taken notice.
Hongyu Li has announced
that the Rust for Linux code is now part of a satellite just launched
out of China. The satellite is running a system called RROS, which follows the old
RTLinux pattern of running a realtime kernel alongside Linux. The realtime
core is written in Rust, using the RFL groundwork.

Despite its imperfections, we still want to share RROS with the
community, showcasing our serious commitment to using RFL for
substantial projects and contributing to the community’s
growth. Our development journey with RROS has been greatly enriched
by the support and knowledge from the RFL community. We also have
received invaluable assistance from enthusiastic forks here,
especially when addressing issues related to safety abstraction

(Thanks to Dirk Behme).

OpenPGP for application developers

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

A new book called OpenPGP for application
developers
has been released under the Creative Commons BY-SA license.

This document is not intended for end-users or implementers of
OpenPGP libraries (or other software that directly handles internal
OpenPGP data structures).

Instead, this document is focused on the second group, application
developers, who use OpenPGP functionality in their software
projects. It describes the properties of the OpenPGP system and its
uses. It presupposes solid knowledge of software development
concepts and of general cryptographic concepts. Thus, this text
describes OpenPGP at the “library-level,” teaching concepts that
will help software developers get started as a user of any
implementation (e.g., OpenPGP.js, Sequoia-PGP).

Security updates for Wednesday

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

Security updates have been issued by Debian (debian-security-support and xorg-server), Fedora (java-17-openjdk, libcmis, and libreoffice), Mageia (fish), Red Hat (buildah, containernetworking-plugins, curl, fence-agents, kernel, kpatch-patch, libxml2, pixman, podman, runc, skopeo, and tracker-miners), SUSE (kernel, SUSE Manager 4.3.10 Release Notes, and SUSE Manager Client Tools), and Ubuntu (gnome-control-center, linux-gcp, linux-kvm, linux-gkeop, linux-gkeop-5.15, linux-hwe-6.2, linux-lowlatency-hwe-6.2, linux-nvidia-6.2, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, netatalk, and pydantic).

The end of vger.kernel.org

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

Konstantin Ryabitsev has announced
that the movement of kernel mailing lists away from the venerable
vger.kernel.org system is nearly complete:

Over the past few months we’ve migrated all of the vger.kernel.org
mailing lists, with the exception of the Big One (linux-kernel, aka
LKML). This list alone is responsible for about 80% of all vger
mailing list traffic, so we left it for the last.

This Thursday, December 14, at 11AM Pacific (19:00 UTC), we will
switch the MX record for vger to point to the new location
(subspace.kernel.org), which will complete the mailing list
migration from the legacy vger server to the new infrastructure.

Graber: LXD now re-licensed and under a CLA

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

The story of Canonical’s takeover of the LXD container manager, and the
subsequent creation of the Incus fork, has been
simmering for a while. Now Incus developer Stéphane Graber reports
that Canonical has changed the license and contribution terms for LXD:

Per the commit message performing the re-licensing, all further
contributions will be under the AGPLv3 license and all
contributions from Canonical employees have been re-licensed to
AGPLv3.

However, Canonical does not own the copyright on any contribution
from non-employees, such as the many changes they have imported
from Incus over the past few months. Those therefore remain under
the Apache2 license that they were contributed under.

As a result, Canonical cannot release LXD under the AGPLv3 license
and likely never will be able to. LXD is now under a weird mix of
Apache2 and AGPLv3 with no clear metadata indicating what file or
what part of each file is under one license or the other.

He also notes that this change will put an end to the flow of patches — in
either direction — between the two projects.

Security updates for Tuesday

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

Security updates have been issued by Debian (libreoffice and webkit2gtk), Fedora (java-1.8.0-openjdk and seamonkey), Oracle (apr, edk2, kernel, and squid:4), Red Hat (postgresql:12, tracker-miners, and webkit2gtk3), SUSE (curl, go1.20, go1.21, hplip, openvswitch, opera, squid, and xerces-c), and Ubuntu (binutils, ghostscript, libreoffice, linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15,
linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gke,
linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-kvm, linux-nvidia,
linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4,
linux-bluefield, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm,
linux-ibm-5.4, linux-kvm, linux-xilinx-zynqmp, postfixadmin, python3.11, and webkit2gtk).

Bottomley: Solving the Looming Developer Liability Problem

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

James Bottomley writes
that open-source developers are increasingly likely to be held liable for
flaws in their code and suggests a solution:

Indemnification means one party, in particular circumstances,
agreeing to be on the hook for the legal responsibilities of
another party. This is actually a well known way not of avoiding
liability but transferring it to where it belongs. As such, it’s
easily sellable in the court of public opinion: we’re not looking
to avoid liability, merely trying to make sure it lands on those
who are making all the money from the code.

[$] Some recent and notable changes to Rust

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

The Rust project makes incremental releases every six
weeks, a fact that makes it easy to overlook some of the
interesting changes coming to the language, such as new
ABIs, better debugger support, asynchronous traits, and
support for C strings.
The end of the year provides an opportunity to look back
over the past several months of updates, and to look
forward to what to expect in 2024.

Kernel prepatch 6.7-rc5

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

The 6.7-rc5 kernel prepatch is out for
testing.

Nothing looks particularly scary, which is good, because if it had
been, I wouldn’t have had the capacity to deal with it last week.

Let’s hope it stays that way even as I am getting better. Because the
holidays are almost upon us, and I’m woefully underprepared.

[$] Modern C for Fedora (and the world)

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

It can be instructive to pull down the dog-eared copy of the first edition
of The C Programming Language that many of us still have on our
bookshelves; the language has changed considerably since that book was
published. Many “features” of early C have been left behind, usually for
good reasons, but there is still a lot of code in the wild that is still
using those features. A concerted effort is being made in both the Fedora
and GCC communities to fix that old code and enable some new errors in the
GCC 14 release (which is in
stage 3
of its development cycle and likely to be released by
mid-2024), but a fair amount of work remains to be done.

[$] Controlling shadow-stack allocation in clone3()

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

User-space shadow stacks are a relatively new feature in Linux; support was
only added for 6.6, and is limited to the x86
architecture
. As support for other architectures (including arm64 and RISC-V) approaches readiness,
though, more thought is going into the API for this feature. As a recent
discussion on the integration of shadow stacks with the clone3() system call shows, there are
still some details to be worked out.