Hírolvasó

Phoronix reports that the days of proprietary NVIDIA graphics drivers are coming to a close.

NVIDIA's open kernel modules is already considered "production ready, opt-in" for data center GPUs. For GeForce and workstation GPUs, the open kernel module code is considered "alpha quality" but will be ramped up moving forward with future releases. NVIDIA has already deprecated the monolithic kernel module approach for their data center GPU support to focus on this open kernel driver solution (and their existing proprietary kernel module using the GSP). Only Turing and newer GPUs will be supported by this open-source kernel driver. Pre-Turing GPUs are left to using the existing proprietary kernel drivers or the Nouveau DRM driver for that matter.

The user-space code remains proprietary, though, which could inhibit the eventual merging of this code into the mainline kernel.

Update: here is NVIDIA's press release on the new drivers.

In a filesystem session at the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Ted Ts'o brought up the subject of filesystems that get resized frequently and whether the default parameters for filesystem creation should change as a result. It stems from a conversation that he had with XFS developer Darrick Wong, who is experiencing some of the same challenges as ext4 in this area. He outlined the problem and how it comes about, then led the discussion on ways to perhaps address it.

Out-of-memory (OOM) situations are dreaded by users, system administrators, and kernel developers alike. Usually, all that is known is that a lot of memory is being used somewhere and the system has run out, but the kernel provides little help to anybody trying to figure out where the memory has gone. In a memory-management session at the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Kent Overstreet asked what could be done to improve OOM reports and reduce the pain for all involved.

Over on the Python Software Foundation (PSF) blog, Alex Waygood has a report from this year's Python Language Summit. There are reports from each of the nine sessions, including "Python without the GIL", The 'Faster CPython' project: 3.12 and beyond", "F-Strings in the grammar", lightning talks, and more.

Memory protection keys are a CPU feature that allows additional access restrictions to be imposed on regions of memory and changed in a fast and efficient way. Support for protection keys in user space has been in the kernel for some time, but kernel-side protection (often called "protection keys supervisor" or PKS) remains unsupported — on x86, at least. At the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Ira Weiny provided an update on the state of PKS and led a discussion on what the proper in-kernel API for PKS should be.

The Rust Blog warns developers of a malicious crate named rustdecimal, which was evidently targeted at GitLab users who mistype rust_decimal.

The crate contained identical source code and functionality as the legit rust_decimal crate, except for the Decimal::new function.

When the function was called, it checked whether the GITLAB_CI environment variable was set, and if so it downloaded a binary payload into /tmp/git-updater.bin and executed it. The binary payload supported both Linux and macOS, but not Windows.

Security updates have been issued by Debian (mutt), Fedora (blender, freerdp, kernel, kernel-headers, kernel-tools, mingw-freetype, and vim), Oracle (kernel and kernel-container), Red Hat (aspell, bind, bluez, c-ares, cairo and pixman, cockpit, compat-exiv2-026, container-tools:3.0, container-tools:rhel8, cpio, dovecot, exiv2, fapolicyd, fetchmail, flatpak, gfbgraph, gnome-shell, go-toolset:rhel8, grafana, grub2, httpd:2.4, keepalived, kernel, kernel-rt, libpq, libreoffice, libsndfile, libssh, libtiff, lynx, maven:3.5, maven:3.6, mod_auth_mellon, mod_auth_openidc:2.3, openssh, php:7.4, pki-core:10.6, postgresql:10, python-lxml, python27:2.7, python3, python38:3.8 python38-devel:3.8, python39:3.9 python39-devel:3.9, qt5-qtbase, qt5-qtsvg, rust-toolset:rhel8, samba, squid:4, udisks2, virt:rhel virt-devel:rhel, webkit2gtk3, xorg-x11-server xorg-x11-server-Xwayland, and zsh), SUSE (gzip and php-composer), and Ubuntu (busybox, cairo, cron, dnsmasq, libsndfile, and nss).

It would have been surprising indeed if the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM) did not include a session working toward solutions to the longstanding problems with get_user_pages(), an internal function that locks user-space pages in memory for access by the kernel. The issue has, after all, come up numerous times over the years. This year's event duly contained a session in the joint filesystem and memory-management track, led by John Hubbard, with a focus on page pinning and how it interacts with filesystems.

In a combined filesystem and memory-management session at the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Paul McKenney gave an update on the changes to the read-copy-update (RCU) subsystem that had been made over the last several years. He started with a quick overview of what RCU is and why it exists at all. He did not go into any real depth, though, since many of the topics could take a 90-minute session of their own, he said, but he did provide some descriptions of the work that has gone into RCU recently.

The 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM) was the first chance for Linux memory-management developers to gather in three years. In a session at the end of the first day led by maintainer Andrew Morton, those developers discussed the memory-management development process. While the overall governance will remain the same, there are nonetheless some significant changes in store for this subsystem.

The Fedora 36 release is now available. Improvements include GNOME 42, Wayland support by default on systems with NVIDIA graphics, Podman 4.0, Ansible 5, the removal of support for legacy ifcfg configuration files, GCC 12, and more; see the release notes for details.

Like much of the kernel, the memory-management subsystem is under-documented, and much of the documentation that does exist is less than fully current. At the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Mike Rapoport ran a session on memory-management documentation and what can be done to improve it. The result was a reinvigorated interest in documentation, but only time will tell what actual improvements will come from that interest.

Security updates have been issued by Debian (kicad and qemu), Fedora (thunderbird), Oracle (expat), Red Hat (samba), Slackware (kernel), and SUSE (firefox, ldb, and rsyslog).

Lennart Poettering designs his ideal desktop operating system in great detail:

First and foremost, I think the focus must be on an image-based design rather than a package-based one. For robustness and security it is essential to operate with reproducible, immutable images that describe the OS or large parts of it in full, rather than operating always with fine-grained RPM/dpkg style packages. That's not to say that packages are not relevant (I actually think they matter a lot!), but I think they should be less of a tool for deploying code but more one of building the objects to deploy.

Robert McQueen describes some initiatives being taken by the GNOME Foundation to attract more users and developers to the platform.

There are many different threats to free access to computing and information in today’s world. The GNOME desktop and apps need to give users convenient and reliable access to technology which works similarly to the tools they already use everyday, but keeps them and their data safe from surveillance, censorship, filtering or just being completely cut off from the Internet. We believe that we can seek both philanthropic and grant funding for this work. It will make GNOME a more appealing and comprehensive offering for the many people who want to protect their privacy.

The problem of negative dentries accumulating in the dentry cache in an unbounded manner, as we looked at back in April, came up at the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM). Negative dentries reflect failed file-name lookups, which are then cached, saving an expensive operation if the file name in question is looked up again. There is no mechanism to proactively prune back those cache entries, however, so the cache keeps growing until memory pressure finally causes the system to forcibly evict some of them, which can make the system unresponsive for a long time or even cause a soft lockup.

One of the memory-management subsystem's most important jobs is reclaiming unused (or little-used) memory so that it can be put to better use. When it comes to one of the core memory-management data structures — page tables — though, this subsystem often falls down on the job. At the 2022 Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM), David Hildenbrand led a session on the problems posed by the lack of page-table reclaim and explored options for improving the situation.

Greg Kroah-Hartman has announced the release of the 5.17.6, 5.15.38, 5.10.114, and 5.4.192 stable kernels. As usual, these contain important fixes throughout the tree; users of those series should upgrade.

Security updates have been issued by CentOS (firefox and thunderbird), Debian (ecdsautils and libz-mingw-w64), Fedora (cifs-utils, firefox, galera, git, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-latest-openjdk, mariadb, maven-shared-utils, mingw-freetype, redis, and seamonkey), Mageia (dcraw, firefox, lighttpd, rsyslog, ruby-nokogiri, and thunderbird), Scientific Linux (thunderbird), SUSE (giflib, kernel, and libwmf), and Ubuntu (dbus and rsyslog).

So, I’ve finally started implementing Pickhardt Payments in Core Lightning (#cln) and there are some practical complications beyond the paper which are worth noting for others who consider this!

In particular, the cost function in the paper cleverly combines the probability of success, with the fee charged by the channel, giving a cost function of:

? log( (ce + 1 ? fe) / (ce + 1)) + ? · fe · fee(e)

Which is great: bigger ? means fees matter more, smaller means they matter less. And the paper suggests various ways of adjusting them if you don’t like the initial results.

But, what’s a reasonable ? value? 1? 1000? 0.00001? Since the left term is the negative log of a probability, and the right is a value in millisats, it’s deeply unclear to me!

So it’s useful to look at the typical ranges of the first term, and the typical fees (the rest of the second term which is not ?), using stats from the real network.

If we want these two terms to be equal, we get:

? log( (ce + 1 ? fe) / (ce + 1)) = ? · fe · fee(e)
=> ? = ? log( (ce + 1 ? fe) / (ce + 1)) / ( fe · fee(e))

Let’s assume that fee(e) is the median fee: 51 parts per million. I chose to look at amounts of 1sat, 10sat, 100sat, 1000sat, 10,000sat, 100,000sat and 1M sat, and calculated the ? values for each channel. It turns out that, for almost all those values, the 10th percentile ? value is 0.125 the median, and the 90th percentile ? value is 12.5 times the median, though for 1M sats it’s 0.21 and 51x, which probably reflects that the median fee is not 51 for these channels!

Nonetheless, this suggests we can calculate the “expected ?” using the median capacity of channels we could use for a payment (i.e. those with capacity >= amount), and the median feerate of those channels. We can then bias it by a factor of 10 or so either way, to reasonably promote certainty over fees or vice versa.

So, in the internal API for the moment I accept a frugality factor, generally 0.1 (not frugal, prefer certainty to fees) to 10 (frugal, prefer fees to certainty), and derive ?:

? = -log((median_capacity_msat + 1 – amount_msat) / (median_capacity_msat + 1)) * frugality / (median_fee + 1)

The median is selected only from the channels with capacity > amount, and the +1 on the median_fee covers the case where median fee turns out to be 0 (such as in one of my tests!).

Note that it’s possible to try to send a payment larger than any channel in the network, using MPP. This is a corner case, where you generally care less about fees, so I set median_capacity_msat in the “no channels” case to amount_msat, and the resulting ? is really large, but at that point you can’t be fussy about fees!