Welcome to the LWN.net Weekly Edition for October 6, 2022

This edition contains the following feature content:

• NVIDIA and nouveau: what will be the future of the nouveau graphics driver given that NVIDIA has released an open-source driver of its own?
• A call to reconsider address-space isolation: keeping address spaces separate from each other imposes a performance cost that is "a bitter pill" to swallow, but the alternative may yet prove to be worse.
• Hybrid scheduling gets more complicated: modern asymmetric CPUs have cores that differ in more ways than just raw clock speed.
• How to fix an ancient GDB problem: a solution for a 15-year-old GDB bug gets closer.
• Some 6.0 development statistics: where the code (and the bugs) in 6.0 came from.
• A discussion on printk(): how to make the kernel's crucial logging function work well with the constraints of realtime systems.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

NVIDIA and nouveau

The release of source code for NVIDIA graphics hardware was perhaps something of a surprise; at least at a quick glance, it seems like that could lead to an in-tree, officially supported driver. For many years, though, the nouveau project has been working on an upstream driver for NVIDIA hardware, so an obvious question is what happens with nouveau in light of the NVIDIA announcement. Kernel graphics maintainer Dave Airlie gave a talk at the 2022 Linux Plumbers Conference (LPC) to help shed some light on that subject.

NVIDIA

He began by giving a brief history of NVIDIA hardware, with a timeline that can be seen in his slides. The timeline was in part "cobbled together from Wikipedia" and is not completely accurate, he said, but shows just "how far back NVIDIA hardware stretches". While the timeline starts in 1999, things started getting interesting in 2006 with the NV50, he said. It introduced the per-context virtual memory addresses; that feature represented a major turning point for graphics hardware.

There is roughly a two-year cadence to the NVIDIA releases starting in 2010 with "Fermi" (GF1xx). Vulkan support was added in the "Kepler" (GK1xx) hardware in 2012. In 2014, "Maxwell" came in two versions (GM1xx and GM2xx); the latter, also known as "Maxwell 2", introduced signed firmware. That pace more or less continued with "Pascal" (GP1xx) in 2016, "Volta" (GV1xx) in 2017, "Turing" (TU1xx) in 2018, and "Ampere" (GA1xx) in 2020. Turing brought support for the GPU system processor (GSP); he explained the importance of that feature a bit later in the talk.

Starting with Maxwell 2, NVIDIA decided that firmware for its devices could not simply be loaded unsigned, for security and other reasons. So firmware needed to be signed by NVIDIA and loaded into the multiple processors on the device. This made life hard for the nouveau project because it required complicated boot sequences for poking multiple firmware images into the device in a specific order that was "very hard to get right".

NVIDIA and nouveau had worked out an arrangement where NVIDIA would provide signed firmware, but it was still difficult to get any of the hardware working. Even when all of the right things were done at boot time, the devices came up in their base configuration. The devices were powered-on and functioning, but "you can't make it reclock, you can't make it go faster". Manually choosing a performance level for NVIDIA devices is known as "reclocking". There was also no power-management functionality available to the driver. This was a watershed moment for nouveau, Airlie said, because it did not make sense to put a lot of effort into a driver for graphics hardware running in its slowest possible mode, while not being battery-friendly either.

The GSP is a RISC-V-based processor that was added to the GPU for the Turing and later hardware. The GPU already had "six or seven little processors on it", but the GSP is meant to be "the one to rule them all". The firmware file for the GSP is around 30 or 40MB; most of the earlier firmware blobs were on the order 256KB, so the GSP is a substantial increase in size. But it is a single firmware image for the device that initializes the rest of the processors. Effectively, NVIDIA moved much of its proprietary kernel driver into the GSP.

That all happened around the same time as the announcement of the open-source NVIDIA kernel drivers, he said. Those are based on a fork of the NVIDIA proprietary driver that only interfaces directly to the GSP; it turns out that there is nothing all that interesting in the API between the kernel and the GSP, so it could be released as open source. Since NVIDIA has customers who are interested in open-source drivers, it makes sense for the company to do so. However, the drivers do not look or act like the existing kernel graphics drivers so they are not able to go into the upstream kernel, Airlie said.

nouveau

That is the current state in the NVIDIA world, which made for a good lead-in to talk about nouveau. That project started in around 2007 to reverse-engineer NVIDIA GPUs to create Linux drivers. It supports hardware from NV04 (1999) through Ampere "in various states of disrepair".

But the project has stagnated some recently due to various factors. One big problem that a community open-source graphics project faces is that once someone gets good at working on it, that becomes known, and they get hired away to work on some other graphics hardware. There is really only one full-time nouveau developer, Ben Skeggs at Red Hat, working on the project.

Also, once the signed firmware came about, with its lack of reclocking and power-management features, it was disheartening for the project; there was no way that the open-source driver was ever going to be able to compete with the proprietary one. It was hard to justify putting in a lot of effort into nouveau. Beyond that, Skeggs spent a lot of time just trying to get the firmware provided by NVIDIA to load and run the hardware.

For the most part, the nouveau kernel driver is just for hardware enablement at this point. The firmware that NVIDIA provides is not the same as what is used by the proprietary driver, so it is not well-tested. Only NVIDIA can really debug problems with that firmware, so there have to be multiple round-trips with NVIDIA engineers. More recently, though, the project has been adding GSP support because that provides a high-level interface to things like reclocking, so the hope is that the nouveau kernel driver can use the standard NVIDIA GSP firmware and drive the hardware that way; "we will see".

OpenGL and Vulkan

There is a nouveau OpenGL driver in Mesa. He believes it has passed the OpenGL 4.5 conformance tests, but has never been submitted for certification. Up until recently, it had "horribly broken multithreading context support" so it worked for older single-threaded games and the like but not for programs like Firefox or modern games; that has been fixed recently, though. The driver has not seen a lot of optimization work, however, due to the lack of reclocking support for the hardware.

A Vulkan driver for nouveau was recently started by Jason Ekstrand, with help from Karol Herbst and Airlie. At the time of the talk, that was a bit of news, but things have progressed since that time. The driver is targeting Vulkan 1.0 for hardware from Kepler up through Ampere and is passing lots of the conformance tests at this point. But in order to finish the driver, and make it work the way they want it to, there is a need to add new user-space APIs to the kernel.

There are three features needed to get Vulkan really working, he said. The first is to split the physical memory allocations (for buffer objects) from the GPU virtual memory allocations. In nouveau, that's all done in one step, which is fine for OpenGL but does not work for Vulkan where more control over the mappings is required.

The second is that synchronization objects and ways to handle and work with them need to be added so that the scheduler can wait for existing GPU work to complete before sending new tasks. It is the way to do proper interleaving of GPU work, Airlie said. The final piece is a virtual-memory-handling interface that is called VM_BIND; it is something that is being looked at for the Intel driver and the amdgpu driver already has many of pieces of it. It is an API both for virtual memory and for command submission that is also geared toward the needs of Vulkan.

Those are all non-trivial projects, he said. Once the GSP support is working and reclocking can be done, these are the next steps for nouveau, but they are going to take some time. The Vulkan driver developers have already started looking at that effort, but there are somewhat circular dependencies that make it difficult to see how to do the work incrementally. It will be a lot of code to review, so getting it into the upstream kernel in a piece-wise fashion will be challenging.

Future

There are some upcoming problems that have not yet been faced, he said. A 30 or 40MB firmware image is rather large; normally, those are put into the initramfs. But putting multiple initramfs images into the boot partition may overrun the space available. The problem gets worse because there may be a need to ship multiple NVIDIA firmware images due to a lack of a stable firmware ABI. The nouveau project will have to pick and choose which firmware versions to support, but each will need to be available; he has wondered if there might be a way to delay firmware loading until after the real root filesystem is mounted, but has not really worked that out yet.

In the long run, it may not really make sense to pound the NVIDIA firmware API into the nouveau driver, which has its own ideas about how everything works. A new driver that leaves behind the existing nouveau legacy and only talks to the GSP using NVIDIA's API may be the right path instead. In addition, the ability to reclock the hardware and accelerate the GPU may allow creating a cross-platform compute stack, to replace the vendor-specific solutions (e.g. CUDA) that exist today. All of those solutions are on their own island, lacking any real developer community, but maybe that could be changed; "we've done it for Vulkan, we've done it for OpenGL, I don't see why we can't do it", though it will take a lot of time—and likely a lot of money.

An audience member asked about Vulkan Compute as a possibility, but Airlie said it was not geared toward the same kinds of problems as CUDA and others. It is better than OpenGL Compute, but is still a long way from what the real compute stacks provide. Ekstrand echoed that, noting that while there is desire to see Vulkan Compute handle more of the "scientific" computing use cases, it will never be a full-stack solution; at most Vulkan can provide the run-time piece, he said.

There was some discussion of the problem with the size of the GSP firmware and initramfs that Airlie had described, including several suggestions of ways to approach the problem. The YouTube video of the talk is available for those who are interested in that discussion or more of the details elsewhere in the talk.

[I would like to thank LWN subscribers for supporting my travel to Dublin for Linux Plumbers Conference.]

Comments (28 posted)

A call to reconsider address-space isolation

When the kernel is running, it has access to its entire address space — usually including all of physical memory — even if only a small portion of that address space is actually needed. That increases the kernel's vulnerability to speculative attacks. An address-space isolation patch set aiming to change this situation has been circulating for a few years, but has never been seriously considered for merging into the mainline. At the 2022 Linux Plumbers Conference, Ofir Weisse sought to convince the development community to reconsider address-space isolation.

Weisse began by pointing out that there seems to be a steady supply of new speculative-execution attacks that need to be mitigated; "Retbleed" is just one of the latest examples. The performance costs of mitigations for these vulnerabilities can be high, to the point that a lot of companies are simply not using them. The cost is also high in terms of development time, with each new variant requiring months of work to address.

Address-space isolation (ASI) is the technique of unmapping memory that is not immediately needed, making it inaccessible to the current running context. Speculative-execution attacks cannot target memory that is not mapped, so the contents of unmapped memory can no longer be exfiltrated via such an attack. One example of ASI is kernel page-table isolation, which was adopted in response to the Meltdown vulnerability. There have been numerous proposals for using ASI in other contexts in recent years, but none have been merged. The specific proposal under discussion in this session is meant to protect hosts against hostile virtual machines.

Wider use of ASI in the kernel would eliminate much of the work of mitigating speculative vulnerabilities, Weisse said. It would reduce the task of addressing a new vulnerability to "three-to-ten lines of code by a single engineer" with no new performance impact. The "new" in that claim is important, though; the ASI patch set itself has a performance impact of 2-14%, depending on which benchmark is run. There is room for improvement in those numbers, though, he said.

The patch set (which is described in more detail in this article) is "a bitter pill" to swallow, he continued. It is large and requires significant changes to the memory-management subsystem and to many calls to allocation functions like kmalloc(). In short, ASI depends on the marking "sensitive" parts of memory that should be shielded from speculative-execution attacks; those are the portions that are unmapped when the isolation is in effect. That means new GFP flags for memory allocations, similar flags for slab creation and vmalloc(), and new annotations for local and global variables. Doing a complete job would require checking each allocation and declaration site and determining whether the memory involved is sensitive or not.

When the kernel hands control to a virtual machine, it first calls asi_enter() to unmap all of the memory that has been marked as being sensitive, making that memory inaccessible to speculative attacks. When that virtual machine exits back into the host kernel, that memory will initially remain unmapped while the host kernel processes the request from the virtual machine. Many of the reasons for a virtual-machine exit can be handled without access to the sensitive memory, he said. In such cases, the request will be handled and control will return to the virtual machine without ever mapping the sensitive memory.

Sometimes, though, there will be a need to access sensitive memory. An important observation here, Weisse said, is that speculative execution will never cause a page fault. So, if the kernel faults while trying to do something with sensitive memory, the access is known to not be speculative; the kernel responds by mapping the sensitive ranges and continuing execution. If simultaneous multi-threading (SMT) is in use, any sibling CPUs will be "stunned" (forced idle) before mapping that memory as an additional defense. On return to the virtual machine, that memory will be unmapped again and sibling CPUs will be resumed.

The key to making this mechanism work well is determining which memory should be classified as being sensitive. Increasing the number of requests that can be handled without mapping sensitive memory will improve both performance and security. This is being done by running various workloads of interest and looking that the percentage of virtual-machine exit events that require mapping sensitive memory; ideally it should be low. In cases where it is not, the task is to look at the memory that is being accessed and determine whether it is sensitive or not. In the latter case, the allocation site can be changed to mark the memory accordingly.

Weisse concluded by saying that ASI could make it easier to address the speculative-execution vulnerabilities that are sure to come in the future with a performance cost that is far less than that imposed by current mitigations. The development community should, he said, reconsider swallowing the bitter pill.

Dave Hansen asked whether ASI could be extended to work more generally on bare-metal systems, rather than being specific to the KVM interface. Weisse answered that it should be possible, but that there would be a lot more work involved to get to that point.

Christian Brauner asked why the patch set had been rejected in the past. Junaid Shahid, who posted the most recent version of this work, said that there hasn't been any real opposition to the idea, but neither has there been much interest in getting it merged. Hansen said that he didn't like it because it is a large amount of code for a fairly narrow use case; it doesn't address the system-call path at all. The need to determine the sensitivity of memory would impose a large maintenance burden in every corner of the kernel, he added.

The session came to a close without any real conclusions on the future of this work. Unless a wave of enthusiasm for ASI materializes from some direction, it seems likely to languish outside of the mainline indefinitely. The pill, it seems, remains too bitter for most developers.

[Thanks to LWN subscribers for supporting my travel to this event.]

Comments (none posted)

Hybrid scheduling gets more complicated

Just over ten years ago, the Arm big.LITTLE architecture posed a challenge for the kernel's CPU scheduler: how should processes be assigned to CPUs when not all CPUs have the same capacity? The situation has not gotten simpler since then; new systems bring new quirks that must be kept in mind for optimal scheduling. At the 2022 Linux Plumbers Conference, Len Brown and Ricardo Neri talked about Intel's hybrid systems and the work that is being done to schedule properly on those systems.

Brown started by describing Intel's hybrid CPUs which, he said, have a combination of "Pcores" and "Ecores". The Pcores have higher performance and also support simultaneous multi-threading (SMT). The Ecores, instead, are more focused on energy efficiency than performance; Ecores were once known as "Atom" CPUs. Both types of CPU implement the same instruction set, so a process can move freely between the two types.

Kernel releases through 4.9 treated all CPUs on these systems as being equal; that meant that any given process would experience variable performance depending on where the scheduler placed it in the system. As of 4.10, Intel's ITMT (standing for "Intel Turbo Boost Max Technology") support caused the scheduler to prefer Pcores over Ecores, all else being equal. That had the effect of putting processes on the faster CPUs when possible, but it also would load all SMT sibling CPUs before falling back to the Ecores, which leads to worse performance overall. That has been fixed as of 5.16; an Ecore will now be preferred over an SMT CPU whose sibling is already busy.

Pcores are faster; they run at a higher clock frequency, but are also able to get more work done with each clock cycle. As a result, clock frequencies alone are not sufficient to compare the capacity of two CPUs in a system. To address this problem, the hardware is able to provide both performance and efficiency scores for each CPU; these numbers can change at run time if conditions change, Brown said.

The situation is actually a bit more complex than that, though. The performance difference between the CPU types depends on which instructions are being executed at any given time. Programs using the VNNI instructions (which are intended to accelerate machine-learning applications) may see much more advantage from running on a Pcore than those that are doing nothing special. There are four different classes of performance, dominated by instruction type, and the ratio of Pcore to Ecore performance is different for each.

To schedule such a system optimally, the kernel should use the Pcores to run the processes that will benefit from them the most. Application developers cannot really be expected to know which of the four performance classes best describes their code, and the appropriate class may change over a program's execution in any case, but the CPU certainly knows which types of instructions are being executed at any given time. So each CPU exposes a register indicating which performance class best describes the currently running process. That allows the kernel to assign a class ID and use it in scheduling decisions.

Neri took over to describe the work that has been done to take advantage of this information. The class ID of each process is stored in its task_struct structure. The first use of this information is in the idle load balancer, which is invoked when a CPU has run out of tasks to execute and looks to see if a task should be pulled from a more heavily loaded CPU elsewhere in the system. This code can look at the class ID of each candidate task to find the one that would benefit the most (or suffer the least) from being moved. This check works at both ends; a task that is making heavy use of instructions that are best run on its current CPU should not be moved if possible.

An audience member asked whether the class ID of a running process can be adjusted from user space. Brown answered that this capability exists for debugging purposes, but that nobody had thought about making it available as a supported feature.

Neri continued that the kernel's NUMA-balancing code can also look at the class IDs and exchange tasks between nodes if that would lead to better system performance. Something similar could also be done with busy load balancing, which tries to even out the load across a busy system. This idea made some developers nervous; it would be easy to break load balancing in ways that create performance regressions that don't come to light until long afterward. Neri emphasized that the class ID would only be used in load-balancing decisions if the existing heuristics led to a tie between two options.

The final moments of the session were dedicated to the problem of scheduling on Intel's Alder Lake CPUs (which started shipping earlier this year). Specifically, the kernel's energy-aware scheduling heuristics don't work well on those CPUs. A number of features present there complicate the energy picture; these include SMT, Intel's "turbo boost" mode, and the CPU's internal power-management mechanisms. For many workloads, running on an ostensibly more power-hungry Pcore can be more efficient than using an Ecore. Time for discussion of the problem was lacking, though, and the session came to a close.

[Thanks to LWN subscribers for supporting my travel to this event.]

Comments (46 posted)

How to fix an ancient GDB problem

The GDB debugger has a long history; it was first created in 1986. It may thus be unsurprising that some GDB development happens over relatively long time frames but, even when taking that into account, the existence of an open bug first reported in 2007 may be a little surprising. At the 2022 GNU Tools Cauldron, GDB maintainer Pedro Alves talked about why this problem has been difficult to solve, and what the eventual solution looks like.

The problem in question, Alves said, has to do with the handling of keyboard interrupts, which normally result from the user hitting control-C. The user's normal expectation is that an interrupt within GDB while the target program is running will stop the program and return the GDB prompt. If, however, that program has blocked the SIGINT signal, the interrupt will never be delivered. At best, GDB will not stop; at worst, the entire debugging session can become stuck and need to be killed from another terminal. GDB users, it seems, tend not to like that behavior.

This problem results from how GDB handles both terminals and interrupt signals. A "session", in the Unix sense, is a set of process groups, all of which share a single controlling terminal. Normally, the debugged process runs in the same session as — and shares the terminal with — GDB, but GDB puts that process into a different process group. Multiple process groups can share a terminal, but only one of those — the foreground group — will receive signals generated by the user at that terminal. GDB normally runs as the foreground group but, when it runs the target program, it designates that program's group as the foreground group instead.

Normally, if the target process receives a SIGINT signal, it will be intercepted by GDB; that happens as part of how tracing with ptrace() works. GDB will respond by stopping the target program and putting out a prompt; the signal is never actually delivered to that program. If, however, the program has blocked SIGINT then the signal remains pending; since it is never delivered, ptrace() has nothing to intercept. That can result in everything getting stuck. There are other paths to the same situation; sigwait() calls, for example, can consume pending signals in a way that causes them to never actually be delivered.

The solution, Alves said, is the same as for any other problem in computer science: add another layer of indirection. In this case, that layer takes the form of a pseudo-terminal (PTY) that is given to the target process rather than the real controlling terminal. GDB then acts as an intermediary between the two terminals. Any output written by the target program to the PTY is simply copied to the real terminal. Input is a bit trickier, since the target can have changed the terminal's modes; GDB has to put the real terminal into raw mode, then copy all of the input from the real terminal into the PTY. When the target is not running, the terminal is put back into "readline mode" for interaction with GDB.

Now, the target can do anything it wants with SIGINT without affecting GDB, which, as the foreground process on the real terminal, can handle events directly. Since that terminal is in raw mode, that means recognizing the interrupt character and responding accordingly. There are other advantages as well; since GDB remains in control of when output goes to the (real) terminal, it can avoid intermixing its own output with that from the target. Another advantage is that GDB is now able to preserve the user's thread selection (the specific thread that debugging activity is focused on) after an interrupt; this wasn't possible before.

There is, he said, an "escape hatch" for anybody wanting the previous behavior; it needs to be there to support other Unix systems in any case.

There were a few other remaining problems, he said. The first process in the foreground process group is considered the "session leader" by the kernel; if that process exits, then its children will be sent a SIGHUP signal. Most applications are not prepared for that and will be killed as a result. Now that the target has its own terminal, it becomes the session leader once it starts. If that process forks and exits, its child processes are likely to meet an untimely end — not the debugging experience that the user is likely to have had in mind.

The solution in this case is a variation on the double-fork technique; before launching the target, GDB will fork twice, with the first process doing nothing but waiting. It will become the session leader; since it doesn't exit, no SIGHUP signals will be generated if the target does surprising things.

GDB still has to be able to stop programs that block SIGINT; for obvious reasons, it cannot use SIGINT for that purpose. The solution here, he said, is to use SIGSTOP, which cannot be blocked, instead.

As is often the case, Emacs users present their own special challenges. Emacs uses control-C for its own purposes, and remaps SIGINT to control-G instead. In cases like this, the user almost certainly wants control-C to be passed through to the target. The answer is a GDB command that allows the user to specify which key should interrupt the process and return to the GDB prompt.

This patch was first prototyped in 2019, but didn't make it to the GDB list until 2021. There were a few problems that turned up at that point, including the session-leader difficulty. Those have all been resolved, and Alves intends to post the patch set again sometime soon. His objective, he concluded, is to post it at least once per year until the problem is finally solved.

[Thanks to LWN subscribers for supporting my travel to this event.]

Comments (20 posted)

Some 6.0 development statistics

Linus Torvalds released the 6.0 kernel on October 2. There were 15,402 non-merge changesets pulled into the mainline for this release, growing the kernel by just over 1.1 million lines of code. As usual, a lot went into the creation of this kernel release; read on for a look at where some of that work came from.

A total of 2,034 developers contributed to the 6.0 release; of those, 236 made their first contribution during this cycle. The total number of developers is just short of the record (2,086) set for 5.19, but the number of first-time contributors is the lowest seen since the 5.6 release (216) in 2020. The most active contributors this time around were:

Most active 6.0 developers

By changesets Sean Christopherson 326 2.1% Krzysztof Kozlowski 314 2.0% Johannes Berg 175 1.1% Charles Keepax 170 1.1% Dmitry Baryshkov 167 1.1% Christoph Hellwig 160 1.0% Jonathan Cameron 146 0.9% Laurent Pinchart 127 0.8% Andy Shevchenko 126 0.8% Pavel Begunkov 125 0.8% Uwe Kleine-König 118 0.8% Matthew Wilcox 108 0.7% Jani Nikula 94 0.6% Pierre-Louis Bossart 92 0.6% Bart Van Assche 88 0.6% Mark Brown 86 0.6% Dan Carpenter 85 0.6% Amit Cohen 84 0.5% Christophe JAILLET 82 0.5% Hans de Goede 81 0.5%

By changed lines Aurabindo Pillai 339519 21.4% Roman Li 155585 9.8% Oded Gabbay 148830 9.4% Zhengjun Xing 140514 8.9% Dmitry Baryshkov 67415 4.3% Ian Rogers 45114 2.8% Jakub Kicinski 28801 1.8% Jiaxin Yu 15008 0.9% Johannes Berg 13464 0.8% Jens Axboe 12294 0.8% Ben Skeggs 11490 0.7% Arnd Bergmann 10481 0.7% Huang Rui 9962 0.6% Edward Cree 9742 0.6% Sean Christopherson 9461 0.6% Rodrigo Siqueira 8016 0.5% Christoph Hellwig 7454 0.5% Krzysztof Kozlowski 7191 0.5% Cheng Xu 6485 0.4% Thomas Bogendoerfer 6309 0.4%

Sean Christopherson was the top contributor of commits this time around; every one of them was an improvement to the KVM subsystem. Krzysztof Kozlowski made a large number of devicetree changes. Johannes Berg has been working intensely on WiFi support, Charles Keepax did a lot of work in the sound subsystem, and Dmitry Baryshkov worked on a number of low-level (mostly Qualcomm) device drivers.

If one has, for some strange reason, a life goal of reaching the top of the "changed lines" column, pursuing a career working on AMD graphics drivers would be a wise course of action; both Aurabindo Pillai and Roman Li added yet more header files to the amdgpu driver. Oded Gabbay did something similar with the Habanalabs accelerator driver, while Zhengjun Xing updated the lists of Intel events for the perf tool.

The top testers and reviewers of patches for 6.0 were:

Test and review credits in 6.0
Tested-by Daniel Wheeler 273 17.6% Alexander Stein 56 3.6% Arnaldo Carvalho de Melo 38 2.5% Philipp Hortmann 36 2.3% Bjorn Andersson 31 2.0% Nícolas F. R. A. Prado 26 1.7% Chen-Yu Tsai 26 1.7% Gurucharan 26 1.7% Conor Dooley 24 1.6% Dmitry Osipenko 23 1.5% Manivannan Sadhasivam 21 1.4% Nicolas Saenz Julienne 20 1.3% Ionela Voinescu 19 1.2% Pierre-Louis Bossart 18 1.2% Jocelyn Falempe 17 1.1%	Reviewed-by Christoph Hellwig 203 2.6% Rob Herring 199 2.5% Andy Shevchenko 177 2.2% Krzysztof Kozlowski 155 2.0% AngeloGioacchino Del Regno 143 1.8% Bard Liao 118 1.5% Ranjani Sridharan 115 1.5% Hans de Goede 103 1.3% Péter Ujfalusi 103 1.3% Darrick J. Wong 93 1.2% Stephen Boyd 90 1.1% Guenter Roeck 86 1.1% David Sterba 84 1.1% Dmitry Baryshkov 78 1.0% Harry Wentland 76 1.0%

Daniel Wheeler continues to be busy, testing nearly four patches per day, every day, during the 6.0 development cycle. The top reviewers were almost equally active. In total, 1,367 commits going into 6.0 (9.0% of the total) contained Tested-by tags, while 5,975 commits (39.1%) contained Reviewed-by tags.

A total of 226 employers supported work on 6.0, down a bit from 5.19. The most active employers were:

Most active 6.0 employers

By changesets Intel 1724 11.2% Google 1191 7.7% (Unknown) 1019 6.6% Linaro 999 6.5% AMD 934 6.1% Red Hat 835 5.4% Huawei Technologies 548 3.6% (None) 483 3.1% Meta 480 3.1% NVIDIA 456 3.0% (Consultant) 398 2.6% SUSE 394 2.6% Oracle 328 2.1% IBM 289 1.9% Arm 279 1.8% MediaTek 245 1.6% Microchip Technology Inc. 221 1.4% NXP Semiconductors 213 1.4% Cirrus Logic 211 1.4% Alibaba 209 1.4%

By lines changed AMD 542077 34.2% Intel 364068 23.0% Linaro 111084 7.0% Google 85886 5.4% Meta 55657 3.5% Red Hat 42893 2.7% NVIDIA 32639 2.1% (Unknown) 30955 2.0% MediaTek 24434 1.5% (None) 18715 1.2% (Consultant) 17473 1.1% NXP Semiconductors 13691 0.9% IBM 13390 0.8% SUSE 12983 0.8% Arm 12182 0.8% Habana Labs 10962 0.7% Huawei Technologies 10709 0.7% Xilinx 10367 0.7% Alibaba 10255 0.6% Renesas Electronics 10048 0.6%

As usual, surprises are hard to come by here, though it is amusing to note that just two companies are responsible for well over half of the lines of code changed in this cycle.

Fixes in 6.0

Of the commits merged for 6.0, 2,781 contained "Fixes" tags indicating where a bug being fixed was first introduced. With a bit of scripting, it is possible to come up with a plot of the time-distribution of the bugs fixed in this development cycle. The result looks like this:

Note that 6.0 also contains 719 commits with Fixes tags pointing to other 6.0 commits; those bugs never appeared in a mainline release, so that line has been left out. As was the case with 5.19, the picture shows that the bugs fixed in 6.0 were introduced all across the Git-era release history; only the 3.4, 2.6.24, 2.6.18, and 2.6.15 releases did not introduce bugs that were fixed in this cycle. The curious can peruse the full list of fixes in 6.0.

Looking at the plot, one might be tempted to wonder what happened in 2.6.35 that required 17 fixes in 6.0. The answer would appear to be a long list of terminal-driver fixes, all addressing problems introduced with the n_gsm line discipline code merged in 2010. That commit is among the most-fixed in the entire kernel history, with no less than 70 patches addressing problems there. It just goes to show, one might conclude, that terminal drivers are so hard that even Alan Cox can't get them right.

At the end of the 6.0 development cycle, one would expect any commits that claim to fix 6.0 bugs to have been merged as part of 6.0 — and, indeed, most of them are. Amusingly, though, the 5.19 kernel contained four commits fixing 6.0 bugs:

• 0326195f523a (bpf: Make sure mac_header was set before using it) fixing f9aefd6b2aa3 (net: warn if mac header was not set)
• 07313a2b29ed (mm: kfence: apply kmemleak_ignore_phys on early allocated pool) fixing 0c24e061196c (mm: kmemleak: add rbtree and store physical address for objects allocated with PA)
• 90f4b5499cdd (rtw88: 8821c: fix access const table of channel parameters) fixing 89d8f53ff6e7 (wifi: rtw88: Fix Sparse warning for rtw8821c_hw_spec)
• 84499c5d220a (drm/aperture: Run fbdev removal before internal helpers) fixing f9aefd6b2aa3 (fbdev: Disable sysfb device registration when removing conflicting FBs)

Good kernel developers try to anticipate and avoid problems; it takes a truly great and prescient developer to write and submit the fix to a bug before that bug itself is merged.

Doing great things is part of the kernel community's job description, though. The 6.1 development cycle is about to start as of this writing; there are currently just over 10,000 non-merge commits waiting in linux-next. That suggests that 6.1 may not be the busiest development cycle ever, but that kernel, which will be a long-term-support release, will still contain a lot of interesting work, including the expected merging of the Rust-for-Linux and multi-generational LRU patch sets. That release can be expected in mid-December; LWN will, of course, stay on top of what's happening throughout that development cycle.

Comments (4 posted)

A discussion on printk()

The kernel's print function, printk(), has been the target of numerous improvement efforts over the years for a variety of reasons. One persistent problem with printk() has been that its latency is unacceptably high for the realtime Linux kernel; at this point, printk() represents the last piece needing changes before the RT_PREEMPT patches can be fully merged. So there have been efforts to rework printk() for latency and lots of other reasons, but those have not made it into the mainline; a recent discussion at the 2022 Linux Plumbers Conference (LPC) seems to have paved the way for new solution to land in the mainline before too long.

A printk() pull request for Linux 6.0 that was rejected by Linus Torvalds sent RT_PREEMPT maintainer Thomas Gleixner back to the drawing board in search of a more acceptable way to finally clean things up. That resulted in a patch set that was posted on September 11, just before the start of LPC. Torvalds said that "it seems to have a sane model" based on a fairly cursory review. John Ogness, who has also been working on printk() issues, scheduled a birds-of-a-feather (BoF) meeting for September 14 to discuss the proposed changes.

Ogness began the meeting by describing (and demonstrating) the new code. When he and Gleixner refer to a "console lock", they are not referring to the existing, global lock for all consoles, Ogness said, but instead to a new per-console lock that would be added. Consoles would also get a state structure so that their status can be tracked. It contains the owning CPU for the console, the console priority (normal, emergency, or panic), and some flags. CPUs also track which priority messages they are currently printing, so that the CPU with the highest-priority messages can actually gain access to the printing kernel thread. There is also some nested priority tracking so that if a CPU is printing at the panic level and that causes a warning, the warning should not start printing and should instead just get added to the ring buffer.

The per-console lock can be acquired by a CPU when it wants to print by specifying the context of what it is printing. It provides a context with the CPU ID, the message priority, and some attributes describing the acquisition type, such as whether it is a friendly or hostile takeover or whether the CPU is willing to spin-wait with a timeout. In the core, there is a single simple rule that governs which CPU gets the console: whichever has the highest-priority message to output. If a warning is being printed, for example, another warning cannot wrest control of the console—its warning will just go into the ring buffer instead—but a panic priority could take control.

Takeovers

Ogness described the process of a friendly takeover. In the example, CPU 0 was currently printing at priority 1 (normal), when CPU 1 wanted to print a warning at priority 2 (emergency); any printing console must check each time it outputs a byte (or at whatever granularity the hardware handles) to see if another CPU needs to print. That console_can_proceed() check looks to see if the priority of the other printing request is higher; if so, it relinquishes the printing to the other CPU, which will then return control to CPU 0 when it is done.

In case CPU 0 has been preempted or cannot relinquish the console in a friendly fashion, there is a facility for a hostile takeover by the CPU with a higher priority printing task. All of the takeovers are accomplished using atomic compare-and-exchange operations. It is important to note that while there is only a single CPU actually physically printing to the console at any given time, other CPUs can still use printk(); the data goes to the ring buffer and will eventually get out to the console—at least that is the hope.

Mathieu Desnoyers asked what happens with the printer thread that has been the subject of a hostile takeover. Ogness said that the console_can_proceed() function will recognize that something has changed in the console state, which indicates the hostile takeover, and it will error out. Gleixner added that policies could be added to determine what to do because the decision is context- and driver-dependent.

Console drivers can mark themselves as being in an unsafe state, or just generally unsafe, so that system policies can determine when and how to use them. For example, in a panic situation, it may be that the system does not want to print on an unsafe console if there is a safe console available; perhaps the persistent store (pstore) driver should be tried before any of the others, but that decision should be made at a different level in the system, he said, not in the core of the console-handling code that is being proposed.

Today, if there are two safe consoles and one unsafe, they will all be written to in order, possibly leading to a single line on the two safe consoles and a lockup on the third so no further data gets printed. The idea is to provide the console drivers with enough information that they can make better decisions on what to do, Ogness said. Instead of just getting a string and a length, they will know the state of things: the message priority, whether the console has been subject to a hostile takeover, and so on. "We have the tools and information to make intelligent decisions" about how best to ensure the output gets to users.

printk() maintainer Petr Mladek asked what happens with any backlog of messages that are still in the ring buffer when a takeover occurs; do the older messages get printed before the new higher-priority message? Gleixner said that currently the older messages are output first. That was done, in part, because that is how things work today, but an argument could be made that a higher-priority message should preempt what's already queued up in the ring buffer. For now, it has to be that way because there will be a mix of new and old drivers; once everything gets converted, different choices could be made.

Incremental

Unlike some of the earlier proposals, this is an incremental approach, Ogness said. There is a new console flag to indicate drivers that implement the mechanisms; that means they provide write_thread() and write_atomic() callbacks and follow the new protocol. write_thread() is called from a thread context, thus it can sleep, while write_atomic() is called from atomic mode so it cannot block. Console drivers will be updated and those that have not (yet) been updated will still continue to function exactly as they currently do. For testing, Gleixner and Ogness used a "a hacked up version of the early uart8250 console", which was posted to the thread as well. The 8250_early console is safe for both reentrancy and non-maskable interrupt (NMI), which made for a reasonable test environment:

[...] we wanted to concentrate on validating the core mechanisms of friendly handover and hostile takeovers instead of dealing with the horrors of port locks or whatever at the same time.

The hope is that the advantages of having threaded and atomic support will put some pressure on console developers to update their code, Ogness said. In the end, only systems that have all of their consoles working under the new scheme will truly benefit from it. He and Gleixner have been working with Daniel Vetter and the graphics developers to try to ensure that the graphics console drivers can be converted to work under the new mechanism.

In answer to a question about partial writes, Ogness noted that there is a per-console sequence counter that is kept in the new state structure. That sequence counter is only updated when a record has been fully printed; if a console gets interrupted by a takeover, it will stop printing mid-record before the sequence counter gets incremented; the CPU that takes over will then pick back up at the beginning of the record. One of the demos would show that behavior, he said.

Steven Rostedt asked about systems with both old and new consoles, which will not gain the benefit of this work; would there be a way to turn off any old-style consoles? Gleixner said that a kernel command-line option will be added to "ignore all old-style consoles". Realtime kernels will need to enforce the use of that option, he said.

Demo

Ogness ran a demo in QEMU that showed the console output of the system on the hacked-up serial console, which was running at 9600bps. He wanted to exaggerate the slowness of a serial console, which continued printing boot messages long after the kernel has actually finished booting. He changed the console to 14,400bps then booted the system again; once it got to the point where threaded printing was active (and running on CPU 0, which is the boot CPU), he caused a warning on CPU 1. Immediately, the printing switched to atomic mode on CPU 1 and continued to print the backlog of boot messages.

Looking at the output, it showed the timestamps of the messages when they actually occurred, not when they were printed, which is a feature of the new mechanism. Roughly seven seconds after the system booted, he triggered the warning, which eventually showed up in the output once the backlog of boot messages had been printed. It showed CPU 1 requesting to print at priority 2 and CPU 0 doing a friendly handover. Then there is a 12-second gap before CPU 1 starts printing the warning because that is how long it took to flush the backlog.

He scrolled back to the point where CPU 1 took over, which shows a partial line from CPU 0 in threaded mode, directly followed by the same line in full as printed by CPU 1 in atomic mode. That looks a little ugly, perhaps, but since it is the same driver and the state tracks what is going on, something cleaner could be done, he said. For example, a newline could be printed after the partial line, Gleixner said. There was also some discussion of having the atomic-mode write prepend some information before it starts outputting the current line (followed by the backlog) to indicate that the console takeover happened at that point.

Gleixner also clarified that the timestamp shown is when the printk() message got added to the ring buffer, not when the printer actually output the message to the console. The backlog is processed before the warning is added to the ring buffer, but that could change. Perhaps it is more important to get the warning information out rather than spend time printing some giant chunk of backlogged messages. All of the shed paint colors are available, "but we are not using any of those paints yet", Gleixner said; maybe it will make sense to do so when all of the console drivers are converted.

Ogness moved on to another demo. In this case, he caused a warning on the boot CPU (CPU 0) once it had gotten to threaded printing mode; that caused the CPU to do a hostile takeover into atomic mode. He then sent an NMI and, since the kernel was built to panic on unknown NMIs, a kernel panic ensued. That started more discussion about the printing order of messages and whether the panic messages should take precedence.

But Torvalds noted that it is important to get the backlog out because it likely contains the context of what caused the further problems. The output from the demo did not look right because it is a made-up example, he said, but in real-world situations, the backlog provides important information and the panic messages will not make sense without them. It is important to ensure that the stack trace and other information gets into the ring buffer and that the backlog gets printed once that has been done.

Gleixner agreed and said that there are lots of details that will need to be worked out over time. The purpose of the meeting was to determine if the approach is reasonable, if it should be pursued, or if they should "just give up and say that printk() is going to be a land mine forever".

Console changes

Greg Kroah-Hartman said that he could not really answer that question without knowing more about what would need to change in the console drivers. Gleixner said that the drivers need to provide the two callbacks; in the case of fairly simple serial drivers like the one they used for testing, the two callbacks are quite similar. More complicated consoles, such as graphics and network consoles, will require more work to decide what can actually be done in atomic context by the write_atomic() callback.

Kroah-Hartman noted that USB serial consoles require enabling interrupts, which will not work in the atomic context; what can be done about those? Gleixner agreed that they will not work in some situations, but the driver will have enough information to make an informed decision and to just return an error or mark itself as unable to be used in an atomic context. Right now, "we do try, pray, and die" for those types of consoles, but they can simply be skipped (or deferred) under the new scheme.

Rostedt asked about trying these skipped consoles after the consoles that can be written from any context are finished. Gleixner said that needs to be an administrative choice because there is a likelihood that trying those other consoles will lock up the system. The kexec developers are concerned that the subsystem will not be reached if console printing locks up the system. It should be possible for the administrator to configure that the logs only go to pstore, for example, to try to ensure that the kexec of a new kernel happens after a crash.

There is a concern that for some systems, such as desktops and embedded systems, the USB serial console is all that is available. The console may not work well (or at all) if it cannot use interrupts, but it might get some amount of information out, which could be critical. It was agreed that there will be some way to indicate that a console of last resort is tried once other, safer possibilities have been exhausted.

It was also agreed that the whole concept of "early consoles" should go away once the consoles have been converted. The write_atomic() callback will handle the early console duties. The hacked-up driver being used for testing does exactly that: it registers as an early console, then just continues running as a regular threaded console once the system reaches the point where threads are available.

After David Woodhouse professed his love for Gleixner (and not for the first time, he said to laughter), Gleixner wanted to make something clear:

printk() is the last thing I am going to clean up in the legacy mess of Linux. Then I am going to hand over to young people who can start cleaning up the stuff I put into the kernel 20 years ago.

With that, the meeting was basically done, though Ogness did show another demo. It would seem that there are no major objections to the direction that is being proposed. Ogness posted a report of the meeting as well as a set of preparation patches, which are now under discussion; Mladek has taken five of the cleanup patches for 6.1. It may take a while to work through the rest, but there is reason for hope that this longtime problem area is being dealt with—that will finally pave the way for the last bits of the RT_PREEMPT patch set to be merged. One guesses that might be cause for a bit of celebration when it happens.

[I would like to thank LWN subscribers for supporting my travel to Dublin for Linux Plumbers Conference.]

Comments (2 posted)

OpenSSH 9.1 released

OpenSSH 9.1 has been released. It is advertised as a bug-fix release (and it addresses a few low-priority memory-safety bugs), but there's also a new option to set the minimum RSA key size for authentication, a few sftp extensions, and more.

Full Story (comments: none)

Kernel release status

The 6.0 kernel is out, released on October 2. Linus said:

So, as is hopefully clear to everybody, the major version number change is more about me running out of fingers and toes than it is about any big fundamental changes.

But of course there's a lot of various changes in 6.0 - we've got over 15k non-merge commits in there in total, after all, and as such 6.0 is one of the bigger releases at least in numbers of commits in a while.

Headline features in 6.0 include a number of io_uring improvements including support for buffered writes to XFS filesystems and zero-copy network transmission, an io_uring-based block driver mechanism, the runtime verification subsystem, and much more; see the LWN merge-window summaries (part 1, part 2) for more information.

Stable updates: 5.19.13 was released on October 4 with an important graphics driver fix. One day later, 5.19.14, 5.15.72, 5.10.147, 5.4.216, and 4.19.261 arrived with the usual collection of fixes.

Comments (none posted)

Quotes of the week

Email is a massively distributed software fuzzing project that lets you transmit messages in the sideband.

— Jani Nikula

There's a lot of weird debate about whether Rust in the kernel is useful or not... in my experience, it's way more useful than I could've ever imagined!

I went from 1st render to a stable desktop that can run run games, browsers, etc. in about two days of work on my driver.

— Asahi Lina

Comments (none posted)

Debian's firmware vote results

The results are in on the Debian project's general-resolution vote regarding non-free firmware in the installer image. The winning option allows the installer image to include firmware necessary to use the system:

We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).

The vote also changes the Debian Social Contract to make it clear that including non-free firmware in this manner is allowed.

Comments (61 posted)

Git 2.38 released

Version 2.38.0 of the Git distributed version-control system has been released. It comes with lots of new features and bug fixes, some of the former are described in a GitHub blog post by Taylor Blau. Highlights include the promotion of the scalar addition for large repositories into Git core, improvements to multi-branch rebase operations with --update-refs, performance improvements, a bash prompt indication for unmerged indexes, and lots more.

Comments (11 posted)

Ekstrand: Introducing NVK

Jason Ekstrand announces a new Vulkan driver for NVIDIA hardware on the Collabora blog. It seems to be off to a good start, but there is some work yet to do:

Normally, I would have submitted the merge request long ago. There are far more alpha-quality drivers already in Mesa. The problem is that we really need a new kernel uAPI to support Vulkan properly and I don't want to be stuck supporting the current nouveau uAPI for the next five years.

Comments (8 posted)

Al-Qudsi: Implementing truly safe semaphores in rust

Mahmoud Al-Qudsi provides extensive details on what it takes to implement a safe semaphore type in the Rust language.

The problem is that with n > 1, there’s no concept of a “privileged” owning thread and all threads that have “obtained” the semaphore do so equally. Therefore, a rust semaphore can only ever provide read-only (&T) access to an underlying resource, limiting the usefulness of such a semaphore almost to the point of having no utility. As such, the only safe “owning” semaphore with read-write access that can exist in the rust world would be Semaphore<()>, or one that actually owns no data and can only be used for its side effect of limiting concurrency while the semaphore is “owned,” so to speak.

Comments (7 posted)

Weston 11.0: what's new, what's next (Collabora blog)

Over on the Collabora blog, Marius Vlad writes about the recent Weston 11.0.0 release. Weston is the reference compositor for the Wayland display server protocol. Vlad looks at features of the release, including some things that are being deprecated and removed, as well as features coming in Weston 12.

Color management infrastructure code has landed that allows HDR [high dynamic range] characteristics to be delivered to an HDR-capable monitor by setting-up HDR metadata in a weston.ini configuration file and delivering that to KMS [kernel mode setting]. Once Weston gains the ability to produce HDR content in a future version, it will come naturally supported.

This new version brings in multiple RDP [remote desktop protocol] improvements, like clipboard pasting, various keyboard language support, bumped support for a newer version of FreeRDP library, and many more other improvements and fixes.

Comments (26 posted)

The Thorny Problem of Keeping the Internet’s Time (New Yorker)

The New Yorker has a lengthy article on the Network Time Protocol and its creator David Mills.

Coders sometimes joke, morbidly, about the “bus factor.” How many people need to get hit by a bus before a given project is endangered? It’s difficult to determine the bus factor for N.T.P., and time synchronization more broadly, especially now that companies such as Google have developed their own N.T.P.-inspired proprietary code. But it seems reasonable to say that N.T.P.’s bus factor is rather small.

Comments (54 posted)

CFP Deadlines: October 6, 2022 to December 5, 2022

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
October 15	December 2 December 3	OLF Conference 2022	Columbus, OH, USA
November 15	December 1 December 4	Karibu PyCon Tanzania	Zanzibar, Tanzania
November 20	February 22 February 24	PGConf India	Bengaluru, India
November 23	March 18 March 19	LibrePlanet	Boston, US
December 2	March 9 March 12	Southern California Linux Expo	Pasadena, CA, US

If the CFP deadline for your event does not appear here, please tell us about it.

Netdev 0x16 accepted sessions announced

The accepted sessions for the upcoming Netdev 0x16 have been posted. The conference will be held virtually and in-person in Lisbon, Portugal October 24-28. In addition, early-bird registration rates have been extended to October 4.

Netdev 0x16, like all the previous netdev conferences, is a conference of the netdev community, by the netdev community, for the netdev community. Linux kernel networking and user space utilization of the interfaces to the Linux kernel networking subsystem are the focus. If you are using Linux as a boot system for proprietary networking, then this conference _may not be for you_.

Comments (none posted)

Events: October 6, 2022 to December 5, 2022

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
October 1 October 7	Akademy 2022	Barcelona, Spain
October 4 October 6	X.Org Developers Conference	Minneapolis, MN, USA
October 11 October 13	Tracing Summit 2022	London, UK
October 13 October 14	PyConZA 2022	Durban, South Africa
October 15 October 16	OpenFest 2022	Sofia, Bulgaria
October 16 October 21	DjangoCon US 2022	San Diego, USA
October 19 October 21	ROSCon 2022	Kyoto, Japan
October 20 October 21	Netfilter workshop	Seville, Spain
October 24 October 28	Netdev 0x16	Lisbon, Portugal
October 24 October 28	KubeCon / CloudNativeCon North America	Detroit, United States
October 25 October 28	PostgreSQL Conference Europe	Berlin, Germany
October 29	PyCon Hong Kong 2022	Hong Kong, Hong Kong
October 29	Minsk Linux User Group meeting	Minsk, Belarus
November 1 November 3	Reproducible Builds Summit 2022	Venice, Italy
November 3 November 14	Ceph Virtual 2022	Online
November 4 November 5	SeaGL 2022	Seattle, US
November 7 November 9	Ubuntu Summit 2022	Prague, Czech Republic
November 8 November 9	Open Source Experience Paris	Paris, France
November 11	Software Supply Chain Offensive Research and Ecosystem Defenses 2022	Los Angeles, USA
November 11 November 12	South Tyrol Free Software Conference	Bolzano, Italy
November 14 November 16	Open Source Monitoring Conference 2022	Nürnberg, Germany
November 26 November 27	UbuCon Asia 2022	Seoul, South Korea
December 1 December 4	Karibu PyCon Tanzania	Zanzibar, Tanzania
December 2 December 3	OLF Conference 2022	Columbus, OH, USA
December 2 December 4	GNOME Asia 2022	Kuala Lumpur, Malaysia

If your event does not appear here, please tell us about it.

Alert summary September 29, 2022 to October 5, 2022

Dist.	ID	Release	Package	Date
Debian	DLA-3136-1	LTS	barbican	2022-10-04
Debian	DSA-5247-1	stable	barbican	2022-10-04
Debian	DSA-5244-1	stable	chromium	2022-09-28
Debian	DSA-5245-1	stable	chromium	2022-10-02
Debian	DLA-3129-1	LTS	gdal	2022-10-01
Debian	DLA-3131-1	LTS	kernel	2022-10-02
Debian	DLA-3135-1	LTS	libdatetime-timezone-perl	2022-10-03
Debian	DLA-3127-1	LTS	libhttp-daemon-perl	2022-09-30
Debian	DLA-3126-1	LTS	libsndfile	2022-09-29
Debian	DLA-3125-1	LTS	libvncserver	2022-09-29
Debian	DLA-3133-1	LTS	lighttpd	2022-10-03
Debian	DSA-5243-1	stable	lighttpd	2022-09-28
Debian	DLA-3114-2	LTS	mariadb-10.3	2022-09-30
Debian	DSA-5246-1	stable	mediawiki	2022-10-04
Debian	DLA-3128-1	LTS	node-thenify	2022-10-01
Debian	DSA-5246-1	stable	php-twig	2022-10-05
Debian	DLA-3132-1	LTS	snakeyaml	2022-10-03
Debian	DLA-3130-1	LTS	tinyxml	2022-09-30
Debian	DLA-3134-1	LTS	tzdata	2022-10-03
Debian	DLA-3124-1	LTS	webkit2gtk	2022-09-29
Fedora	FEDORA-2022-5b644a935b	F35	bash	2022-10-05
Fedora	FEDORA-2022-4ff296fe8e	F36	bash	2022-09-30
Fedora	FEDORA-2022-3ca063941b	F35	chromium	2022-10-05
Fedora	FEDORA-2022-b49c9bc07a	F36	chromium	2022-10-05
Fedora	FEDORA-2022-bafb72fdc0	F35	enlightenment	2022-10-03
Fedora	FEDORA-2022-0cc77b384a	F36	enlightenment	2022-10-03
Fedora	FEDORA-2022-1f8312716f	F35	firefox	2022-09-29
Fedora	FEDORA-2022-b60ea83571	F36	gajim	2022-09-29
Fedora	FEDORA-2022-d718af66d1	F36	kitty	2022-10-02
Fedora	FEDORA-2022-3dd3274ae2	F35	libdxfrw	2022-10-04
Fedora	FEDORA-2022-c9028047bf	F35	libofx	2022-09-29
Fedora	FEDORA-2022-3dd3274ae2	F35	librecad	2022-10-04
Fedora	FEDORA-2022-c26b19568d	F35	lighttpd	2022-10-05
Fedora	FEDORA-2022-cdeabe1bc0	F35	postgresql-jdbc	2022-10-05
Fedora	FEDORA-2022-d7d49b2fac	F36	postgresql-jdbc	2022-10-05
Fedora	FEDORA-2022-b60ea83571	F36	python-nbxmpp	2022-09-29
Fedora	FEDORA-2022-5a74a5eea7	F37	python-oauthlib	2022-10-04
Fedora	FEDORA-2022-07dd9375b2	F35	scala	2022-10-05
Fedora	FEDORA-2022-34acf878fb	F36	scala	2022-10-05
Fedora	FEDORA-2022-df4ffc6551	F36	thunderbird	2022-10-01
Gentoo	202209-16		bluez	2022-09-29
Gentoo	202209-23		chromium	2022-09-29
Gentoo	202209-24		expat	2022-09-29
Gentoo	202209-27		firefox	2022-09-29
Gentoo	202209-26		go	2022-09-29
Gentoo	202209-19		graphicsmagick	2022-09-29
Gentoo	202209-22		kitty	2022-09-29
Gentoo	202209-20		php	2022-09-29
Gentoo	202209-21		poppler	2022-09-29
Gentoo	202209-17		redis	2022-09-29
Gentoo	202209-18		thunderbird	2022-09-29
Gentoo	202209-25		zutty	2022-09-29
Mageia	MGASA-2022-0358	8	bash	2022-10-05
Mageia	MGASA-2022-0357	8	chromium-browser-stable	2022-10-05
Mageia	MGASA-2022-0352	8	expat	2022-10-01
Mageia	MGASA-2022-0348	8	firejail	2022-10-01
Mageia	MGASA-2022-0356	8	golang	2022-10-05
Mageia	MGASA-2022-0353	8	libjpeg	2022-10-01
Mageia	MGASA-2022-0354	8	nodejs	2022-10-01
Mageia	MGASA-2022-0349	8	perl-HTTP-Daemon	2022-10-01
Mageia	MGASA-2022-0350	8	python-mako	2022-10-01
Mageia	MGASA-2022-0351	8	squid	2022-10-01
Mageia	MGASA-2022-0355	8	thunderbird	2022-10-01
Oracle	ELSA-2022-6765	OL7	bind	2022-10-03
Oracle	ELSA-2022-6765	OL7	bind	2022-10-03
Oracle	ELSA-2022-6778	OL8	bind	2022-10-05
Oracle	ELSA-2022-6763	OL9	bind	2022-10-03
Oracle	ELSA-2022-6781	OL8	bind9.16	2022-10-05
Oracle	ELSA-2022-6702	OL8	firefox	2022-09-28
Oracle	ELSA-2022-6700	OL9	firefox	2022-09-28
Oracle	ELSA-2022-6775	OL8	squid:4	2022-10-05
Oracle	ELSA-2022-6708	OL8	thunderbird	2022-09-28
Oracle	ELSA-2022-6717	OL9	thunderbird	2022-09-28
Red Hat	RHSA-2022:6783-01	EL8	RHSSO	2022-10-04
Red Hat	RHSA-2022:6765-01	EL7	bind	2022-10-03
Red Hat	RHSA-2022:6778-01	EL8	bind	2022-10-04
Red Hat	RHSA-2022:6764-01	EL8.1	bind	2022-10-03
Red Hat	RHSA-2022:6780-01	EL8.2	bind	2022-10-04
Red Hat	RHSA-2022:6779-01	EL8.4	bind	2022-10-04
Red Hat	RHSA-2022:6763-01	EL9	bind	2022-10-03
Red Hat	RHSA-2022:6781-01	EL8	bind9.16	2022-10-04
Red Hat	RHSA-2022:6753-01	EL7	httpd24-httpd	2022-09-29
Red Hat	RHSA-2022:6755-01	EL7	java-1.7.1-ibm	2022-09-29
Red Hat	RHSA-2022:6756-01	EL7	java-1.8.0-ibm	2022-09-29
Red Hat	RHSA-2022:6741-01	EL7.7	kernel	2022-09-28
Red Hat	RHSA-2022:6766-01	EL7	rh-python38-python	2022-10-03
Red Hat	RHSA-2022:6775-01	EL8	squid:4	2022-10-04
Red Hat	RHSA-2022:6774-01	EL8.1	squid:4	2022-10-04
Red Hat	RHSA-2022:6777-01	EL8.2	squid:4	2022-10-04
Red Hat	RHSA-2022:6776-01	EL8.4	squid:4	2022-10-04
Scientific Linux	SLSA-2022:6765-1	SL7	bind	2022-10-04
Scientific Linux	SLSA-2022:6711-1	SL7	firefox	2022-09-30
Scientific Linux	SLSA-2022:6710-1	SL7	thunderbird	2022-09-30
Slackware	SSA:2022-271-01		xorg	2022-09-28
SUSE	SUSE-SU-2022:3487-1	MP4.3 SLE15 oS15.4	ImageMagick	2022-10-01
SUSE	SUSE-SU-2022:3499-1	OS9 SLE12	bind	2022-10-04
SUSE	SUSE-SU-2022:3500-1	SLE12	bind	2022-10-04
SUSE	SUSE-SU-2022:3480-1	MP4.1 SLE15 SES6 SES7	buildah	2022-09-30
SUSE	openSUSE-SU-2022:10138-1	osB15	chromium	2022-10-03
SUSE	openSUSE-SU-2022:10139-1	osB15	chromium	2022-10-03
SUSE	SUSE-SU-2022:3525-1	MP4.3 SLE15 SLE-m5.3 oS15.4	cifs-utils	2022-10-05
SUSE	SUSE-SU-2022:3496-1	MP4.3 SLE15 SLE-m5.3 oS15.4	colord	2022-10-04
SUSE	openSUSE-SU-2022:10134-1	osB15	connman	2022-09-30
SUSE	SUSE-SU-2022:3486-1	MP4.3 SLE15 oS15.4	cosign	2022-10-01
SUSE	SUSE-SU-2022:3489-1	MP4.3 SLE15 SLE-m5.3 oS15.4	expat	2022-10-01
SUSE	SUSE-SU-2022:3466-1	OS9 SLE12	expat	2022-09-29
SUSE	SUSE-SU-2022:3471-1	OS9 SLE12	krb5-appl	2022-09-29
SUSE	SUSE-SU-2022:3493-1	SLE15 SES6	libcroco	2022-10-04
SUSE	SUSE-SU-2022:3494-1	MP4.1 MP4.2 SLE15 SES7 oS15.3 oS15.4	libgit2	2022-10-04
SUSE	SUSE-SU-2022:3495-1	MP4.1 SLE15 SES6 SES7 oS15.3 oS15.4	libgit2	2022-10-04
SUSE	SUSE-SU-2022:3523-1	MP4.2 SLE15 SLE-m5.1 SLE-m5.2 oS15.3 oS15.4 osM5.2	libjpeg-turbo	2022-10-04
SUSE	SUSE-SU-2022:3475-1	SLE12	libjpeg-turbo	2022-09-30
SUSE	SUSE-SU-2022:3456-1	MP4.1 MP4.2 SLE15 SES7 oS15.3	libostree	2022-09-28
SUSE	SUSE-SU-2022:3455-1	SLE15 SES6	libostree	2022-09-28
SUSE	openSUSE-SU-2022:10132-1	osB15	lighttpd	2022-09-29
SUSE	openSUSE-SU-2022:10140-1	osB15	lighttpd	2022-10-03
SUSE	SUSE-SU-2022:3503-1	SLE12	nodejs12	2022-10-04
SUSE	SUSE-SU-2022:3516-1	SLE12	nodejs14	2022-10-04
SUSE	SUSE-SU-2022:3524-1	SLE12	nodejs16	2022-10-05
SUSE	SUSE-SU-2022:3512-1	MP4.2 SLE15 oS15.3 oS15.4	python	2022-10-04
SUSE	SUSE-SU-2022:3511-1	SLE12	python3	2022-10-04
SUSE	SUSE-SU-2022:3460-1	SLE12	python3-lxml	2022-09-29
SUSE	SUSE-SU-2022:3461-1	SLE12	python3-lxml	2022-09-29
SUSE	SUSE-SU-2022:3473-1	MP4.3 SLE15 oS15.4	python310	2022-09-30
SUSE	SUSE-SU-2022:3483-1	SLE12	python36	2022-09-30
SUSE	SUSE-SU-2022:3485-1	MP4.2 SLE15 oS15.3 oS15.4	python39	2022-10-01
SUSE	SUSE-SU-2022:3451-1	MP4.2 MP4.3 SLE15 oS15.3 oS15.4	rust1.62	2022-09-28
SUSE	SUSE-SU-2022:3497-1	SLE12	slurm	2022-10-04
SUSE	SUSE-SU-2022:3468-1	SLE15 oS15.3 oS15.4	slurm	2022-09-29
SUSE	SUSE-SU-2022:3490-1	SLE15 oS15.3 oS15.4	slurm	2022-10-03
SUSE	SUSE-SU-2022:3454-1	SLE12	slurm_18_08	2022-09-28
SUSE	SUSE-SU-2022:3462-1	SLE15 oS15.3 oS15.4	slurm_18_08	2022-09-29
SUSE	SUSE-SU-2022:3477-1	SLE12	slurm_20_02	2022-09-30
SUSE	SUSE-SU-2022:3491-1	SLE15 oS15.3 oS15.4	slurm_20_02	2022-10-03
SUSE	SUSE-SU-2022:3457-1	MP4.1 MP4.2 SLE15 SES7 oS15.3	vsftpd	2022-09-28
SUSE	SUSE-SU-2022:3458-1	SLE15 SES6	vsftpd	2022-09-28
SUSE	SUSE-SU-2022:3488-1	MP4.3 SLE15 oS15.4	webkit2gtk3	2022-10-01
SUSE	SUSE-SU-2022:3492-1	OS9 SLE12	webkit2gtk3	2022-10-03
SUSE	SUSE-SU-2022:3502-1	SLE15 SES6	webkit2gtk3	2022-10-04
Ubuntu	USN-5656-1	16.04	jackd2	2022-10-04
Ubuntu	USN-5646-1	16.04	libxi	2022-09-28
Ubuntu	USN-5650-1	14.04 16.04	linux, linux-aws, linux-kvm, linux-lts-xenial	2022-09-30
Ubuntu	USN-5652-1	14.04 16.04	linux-azure	2022-10-03
Ubuntu	USN-5647-1	20.04	linux-gcp	2022-09-28
Ubuntu	USN-5654-1	20.04	linux-gke	2022-10-04
Ubuntu	USN-5648-1	20.04	linux-gke-5.15	2022-09-30
Ubuntu	USN-5655-1	22.04	linux-intel-iotg	2022-10-04
Ubuntu	USN-5645-1	16.04	postgresql-9.5	2022-09-28
Ubuntu	USN-5653-1	20.04 22.04	python-django	2022-10-04
Ubuntu	USN-5615-2	16.04	sqlite3	2022-09-28
Ubuntu	USN-5651-2	14.04 16.04	strongswan	2022-10-03
Ubuntu	USN-5651-1	18.04 20.04 22.04	strongswan	2022-10-03
Ubuntu	USN-5614-2	16.04	wayland	2022-10-03

Full Story (comments: none)