Welcome to the LWN.net Weekly Edition for October 11, 2018

This edition contains the following feature content:

• Advances in Mesa continuous integration: the quality of the Mesa project is much improved through the use of extensive automatic integration tests.
• A status update for virgl: an update on the Virgil virtual 3D GPU project.
• What's a CPU to do when it has nothing to do?: doing nothing efficiently is harder than it seems.
• New AT_ flags for restricting pathname lookup: hardening file operation by restricting how file names can be looked up.
• Some numbers from the 4.19 development cycle: who contributed to the 4.19 kernel and who supported that work.
• The modernization of PCIe hotplug in Linux: a detailed technical look at the work being done to make it possible to safely plug and unplug PCIe devices.

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)

Advances in Mesa continuous integration

Continuous integration (CI) has become increasingly prevalent in open-source projects over the last few years. Intel has been active in building CI systems for graphics, both for the kernel side and for the Mesa-based user-space side of the equation. Mark Janes and Clayton Craft gave a presentation on Intel's Mesa CI system at the 2018 X.Org Developers Conference (XDC), which was held in A Coruña, Spain in late September. The Mesa CI system is one of the earliest successful CI initiatives in open source that he knows of, Janes said. It is a core component of Mesa development, especially at Intel.

Like many companies, Intel is a large organization with an "old school development model". He likened it to a Roman army, where there are legions that are made up of smaller groups, each of which has procedures for all of its activities; tents are set up and arranged the same way each time. When Intel first encountered Mesa development, it was something of a shock. There were no architects in the group, but the Mesa developers were simply running right through the Intel army.

There is a tendency to be smug and dismissive of the other parts of the companies that we work in, he said. He thinks it makes more sense to take the time to explain why the open-source methodology is superior. For 50 years, building software has been about differentiation and competing, but part of the open-source model is to collaborate with competitors. He thinks open-source has an unbeatable advantage, but it is still the underdog in many respects; it is "a lot of fun to be an underdog with an advantage", Janes said.

Technical details

He turned things over to Craft, who went over some of the technical details of the CI system. It has roughly 200 machines with full Intel hardware coverage going back to 2007. It runs multiple test suites, including piglit and the conformance test suites (CTS) for Vulkan, OpenGL, and OpenGLES. It does build tests of non-Intel platforms for Android as well. Each commit to the mainline kicks off millions of tests. Users can add their development branches to the CI system, as well, so that commits to those get tested before the code ever ends up in the mainline.

The target execution time for these tests is 30 minutes or less; otherwise, it doesn't really fit well with a developer's workflow. There is a "very very low false positive rate", Craft said, of about 0.0001%, so developers can be confident that the reports they get are accurate. For various performance tests, it can generate trend lines that make performance regressions easy to spot. The implementation of the CI system is open source and available on GitLab; "steal our stuff", he suggested.

Janes said that when the project started, there were no real success stories for testing in open source, nor was there a testing framework available to be used. Being transparent with the results of the testing and the progress of the CI system has helped with its adoption. Having a really low false positive rate, wide coverage, and rapid turnaround has helped as well. He likened working in a project to living with friends as roommates; at first it is great, but eventually the dishes start to pile up and no one wants to deal with them. The CI system is meant to help developers get along; it is the automatic dishwasher for the community, he said.

Stats and graphs

Statistics are useful, but they can also be misused. Some stats are easy to collect and highly visible, but do not necessarily correlate to the measures that get imparted to them. For example, tracking and prominently showing the number of commits in a particular area can lead to more white-space commits or to splitting commits with an eye toward boosting those numbers, he said.

That said, he started showing graphs from their slides [PDF]. He started with a graph that showed both the number of commits and the number of CI builds for each developer with more than 30 commits since the CI system started in August 2014. One thing it shows is that an active developer can also be an active user of the CI system—several of the most active developers have nearly as many CI builds as commits. Some other developers are perhaps trying to be extra safe and do more CI builds than commits, or maybe they are simply new to Mesa and are learning. In general, for those using the CI system, the number of builds was roughly on the same level as the number of commits.

Janes then described two ways to track bugs that get introduced into Mesa: reverts and fixes. Reverts are as old as Git, but fixes are relatively new. The "Fixes" tag was introduced in 2017; it notes the commit ID that is being fixed. In both cases, the "offending" commit ID can be extracted, thus the developer who introduced the bug can be identified. The Fixes tag is used to help automate the inclusion of commits into bug-fix releases.

For the following graphs, he removed the names of the developers, and just identified them by the number of commits they made over the period that the graph covered. He showed a graph of the percentage of fixes per commit as well as the number of CI builds since the Fixes tag was adopted in 2017. As might be guessed, those who are heavy users of CI tend to have much lower rates of patches needing Fixes. He joked that since the names were not on the graph, he would be happy to accept beer from any developer who wanted to ensure that no one would ever know which entry on the graph was theirs.

Looking at CI builds and reverts back to the start of the CI era in 2014 shows a similar correlation to the Fixes graph, though the signal is somewhat noisier. But heavier users of the CI system tend to have fewer reverts, in general.

There is quite a bit of work that goes into ensuring that the CI test results are useful and do not contain known failure cases, Craft said. There are lots of tests that will never run on certain platforms, so those need to be filtered out of the test results. That way, spurious failures will not clutter inboxes or the CI status web site.

In addition, once a bug has been identified stemming from a particular commit, and the developer has been notified, it does not help other developers to get notified of that problem. Craft said that he and Janes identify these commits and configure the CI system to expect the failing test(s).

At that point, though, when someone fixes the problem, the test will start passing, which could seem like a failure to the CI system. Switching back to the pre-bug CI configuration will fix that problem. But a development branch that was made before the fix will not pass the test. It can't use the post-fix configuration. So the CI configuration files are tracked in Git and the changes to the test results are tagged with commit IDs. That way branches will only have failures caused by changes on the branch and the mainline will reflect known bugs and fixes properly.

Those configuration files can be used to gather some statistics about test regressions, Janes said. For the i965 driver, commits that regressed the tests were generally fewer for those who used the CI system more. He summed up his case by saying that CI is helpful for developers, those who use it love it because they don't like having their commits reverted and the CI system allows them to avoid that. At Intel, it is believed that use of CI has a multiplicative effect on the rate of development, he said.

CI hardware

There are around 200 computers in the CI system, Craft said. On average, they are about $400 systems but, in reality, most of the money goes for the high-end, new systems. The project got the older systems for free or for pennies on the dollar from eBay.

There are servers, desktops, and laptops represented, though the builds for those systems are done on dedicated Xeon systems. Craft showed some pictures of the CI hardware, which consists of "a lot of systems in a small amount of space". Various tricks have been used to squeeze more into that space, including an innovative use of Ikea napkin holders to store laptops vertically.

As part of the talk, Intel is announcing a new, public CI results site. Previously, those outside of Intel would get an email with the results of their CI run that they would need to parse to figure out what went wrong. Those inside of Intel could use the Jenkins web site, but it took a long time for pages to appear. The old site would take nearly a minute and a half, while the new site is just over half a second.

Janes and Craft took a test drive through the new site, which provides lots of information about what builds were tested and what the outcome was. If tests failed, one can drill down to see the test output, history, and more. For example, piglit did not build earlier on the day of the talk, but because of the CI system, it was noticed and fixed before many developers even knew it was broken, Janes said.

In the Q&A, Janes suggested that those who want to have their own tests run get them added to piglit or another of the community test suites. He also said that it is difficult to identify a small subset of tests that give a good indication of driver health in, say, one minute. He noted that all of the work on the new CI web site was mostly done to support those outside of Intel; other than speeding up web site loading time, it didn't really provide anything new to Intel developers. Janes and Craft clearly hope that more Mesa developers will use the system and that all of Mesa development will benefit.

[I would like to thank the X.Org Foundation and LWN's travel sponsor, the Linux Foundation, for travel assistance to A Coruña for XDC.]

Comments (17 posted)

A status update for virgl

At the 2018 X.Org Developers Conference, Elie Tournier gave an update on the state of the Virgil (or virgl) virtual 3D GPU for QEMU. He looked at the project's history along with what has happened with it over the last year or so. As is usual in a status update talk, he finished with some thoughts about future plans for virgl. For the last year, Tournier has been working on virgl for Collabora.

Virgil began as a Dave Airlie side project four or five years ago. Tournier recommended a YouTube video of a 2014 linux.conf.au talk that Airlie gave as a good starting point. It is meant to be a way for guests running in a virtual machine (VM) to access the host GPU using OpenGL and other APIs. It is based on Gallium3D, because Airlie was familiar with that architecture, Tournier said. It has reached the stage where it is ready for use in products. A company is currently building a project using it; in addition, QEMU is using virgl to allow Windows guests to access the GPU. Overall, virgl is in pretty good shape, he said.

The virgl stack consists of an application running in the guest that sends OpenGL to the Mesa virgl driver, which uses the virtio-gpu driver in the guest kernel to communicate with QEMU on the host. QEMU has its own virtio-gpu component as well as virglrenderer, which provides the OpenGL commands to the host driver. The application will send GLSL to Mesa, which will convert it to TGSI. That was used because it is easier to transfer than the GLSL intermediate representation (IR). But the TGSI then gets converted back to GLSL by virglrenderer on the host. "It is a simple way, but we know that TGSI is not the best IR", he said.

He briefly gave an overview of resource allocation for virgl, but cautioned that he is not an expert in that area. The guest driver creates resources and allocates memory. Those requests are passed through virtio-gpu to the host side; either QEMU or virglrenderer then allocate the memory for the host. The guest writes data into its memory and requests a transfer to the host, which causes the host to copy the guest data into its buffers.

At last year's XDC, only OpenGL 3.0 using the OpenGL backend on the host was supported. Lots of work has been done since then. Now virgl supports OpenGL 4.3 and OpenGL ES 3.2 in the VM using both OpenGL and OpenGL ES backends on the host. Using the OpenGL ES backend does require SDL in order to set up the OpenGL ES context. All of that work is now upstream, he said.

The conformance test suites (CTS) have been run on the guest. For OpenGL ES 2 on both backends, there are zero failures. OpenGL ES 3 is in good shape on the OpenGL backend, but has three failures on the OpenGL ES backend, which are still being worked on. OpenGL ES 3.2 on both backends has no failures, but there are 3397 tests that are not supported because virgl does not implement some functions and extensions, Tournier said. The virgl developers have found that randomizing the order of the CTS tests can cause some state leaks and, thus, failures; that is being looked into as well.

Collabora's primary goal for this work was to enable OpenGL ES on both the guest and host; at the beginning, making OpenGL better was not something the developers were thinking about. They needed to add various workarounds to support OpenGL ES; in addition, there are lots of different formats that are supported by OpenGL ES, but not by OpenGL, so those needed to be added.

Debugging virgl is "very painful", he said. When the tests fail, the problem can be anywhere in the stack: the Mesa driver or kernel in the guest, copying from the guest to the host, or the QEMU or driver on the host. They have tried to improve the debugging by adding additional debug modes in virglrenderer, but it is still difficult. An API trace in QEMU will be hundreds of thousands of lines, for example.

He showed some performance numbers (which can be seen in slide 13 in his slides [PDF]) from running on his Kabylake-based system. Using the QEMU guest with the OpenGL backend was quite stable, but for the UNIGINE Valley and UNIGINE Heaven tests, the frames-per-second (fps) values seem fairly low (37.3 for the host versus 2.1 for UNIGINE Heaven). There is another test mode that virglrenderer provides (Vtest), which allows using WebSockets to pass the OpenGL commands so that QEMU is bypassed; that ran UNIGINE Heaven at 13.4fps. On a synthetic GPU test, the frame rate was nearly the same between the host, QEMU guest, and Vtest guest. The slide also pointed to a mailing list post from his colleague with some discussion and more results.

On the infrastructure side of things, the project makes heavy use of the freedesktop.org GitLab site. Pull requests and bug reports are handled there; virgl was one of the first projects to move to the new freedesktop.org infrastructure, he said. There is work being done on a continuous integration (CI) system for virgl, though it is a difficult problem, Tournier said, because of all the different components that go into it.

For the future, the project plans to improve and release the CI system. It will also be looking at the remaining piglit and CTS failures in order to fix those. There is a need to improve the security of virgl; many are running VMs to provide compartmentalization, so guests should not be able to access random pages in the host, which may be the case right now. There is a fuzzer being run, but it is mostly for the API, rather than for other parts of the stack. There is also an effort to get rid of the data copies from the guest to the host by providing a single set of buffers that can be used by both.

There are plans to support Vulkan in virgl. The work was started by a Google Summer of Code student and is available in his GitHub repository. Using Vulkan is nice, Tournier said, because instead of sending TGSI and converting back and forth, SPIR-V can be used from the guest all the way to the host driver. Removing the conversions also makes virgl more stable and secure, since many of the crashes come from conversion failures.

He showed that he was running the desktop and slide-display application in a VM using virgl to the OpenGL ES backend on his laptop. He started up a game (Those Funny Funguloids) that was not too demanding in terms of 3D performance, he said. Both his desktop and the game ran smoothly. His laptop is not powerful enough to run some of the truly demanding games, but systems with a beefy graphics card can run many of the latest games, he said.

As with all projects, virgl is looking for contributors to "join the party". There is the repository, the #virgil3d IRC channel, and the virglrenderer-devel mailing list for those interested. In addition, a YouTube video of Tournier's talk is available.

[I would like to thank the X.Org Foundation and LWN's travel sponsor, the Linux Foundation, for travel assistance to A Coruña for XDC.]

Comments (none posted)

What's a CPU to do when it has nothing to do?

It would be reasonable to expect doing nothing to be an easy, simple task for a kernel, but it isn't. At Kernel Recipes 2018, Rafael Wysocki discussed what CPUs do when they don't have anything to do, how the kernel handles this, problems inherent in the current strategy, and how his recent rework of the kernel's idle loop has improved power consumption on systems that aren't doing anything.

The idle loop, one of the kernel subsystems that Wysocki maintains, controls what a CPU does when it has no processes to run. Precise to a fault, Wysocki defined his terms: for the purposes of this discussion, a CPU is an entity that can take instructions from memory and execute them at the same time as any other entities in the same system are doing likewise. On a simple, single-core single-processor system, that core is the CPU. If the processor has multiple cores, each of those cores is a CPU. If each of those cores exposes multiple interfaces for simultaneous instruction execution, which Intel calls "hyperthreading", then each of those threads is a CPU.

A CPU is idle if there are no tasks for it to run. Or, again more precisely, the Linux kernel has a number of internal scheduling classes, including the special idle class. If there are no tasks to run on a given CPU in any of those classes save the idle class, the CPU is regarded as idle. If the hardware doesn't make allowance for this, then the CPU will have to run useless instructions until it is needed for real work. However, this is a wildly inefficient use of electricity, so most CPUs support a number of lower-power states into which the kernel can put them until they are needed to do useful work.

Idle states are not free to enter or exit. Entry and exit both require some time, and moreover power consumption briefly rises slightly above normal for the current state on entry to idle and above normal for the destination state on exit from idle. Although increasingly deep idle states consume decreasing amounts of power, they have increasingly large costs to enter and exit. This implies that for short idle periods, a fairly shallow idle state is the best use of system resources; for longer idle periods, the costs of a deeper idle state will be justified by the increased power savings while idle. It is therefore in the kernel's best interests to predict how long a CPU will be idle before deciding how deeply to idle it. This is the job of the idle loop.

In this loop, the CPU scheduler notices that a CPU is idle because it has no work for the CPU to do. The scheduler then calls the governor, which does its best to predict the appropriate idle state to enter. There are currently two governors in the kernel, called "menu" and "ladder". They are used in different cases, but they both try to do roughly the same thing: keep track of system state when a CPU idles and how long it ended up idling for. This is done in order to predict how long a freshly-idle CPU is likely to remain so, and thus what idle state is most appropriate for it.

This job is made particularly difficult by the CPU scheduler's clock tick. This is a timer that is run by the CPU scheduler for the purpose of time-sharing the CPU: if you are going to run multiple jobs on a single CPU, each job can only be run for a while, then periodically put aside in favor of another job. This tick doesn't need to run on a CPU that is idle, since there are no jobs between which the CPU should be shared. Moreover, if the tick is allowed to run on an otherwise-idle CPU, it will prevent the governor from selecting deep idle states by limiting the time for which the CPU is likely to remain idle. So in kernels 4.16 and older, the scheduler disables the tick before calling the governor. When the CPU is woken by an interrupt, the scheduler makes a decision about whether there's work to do and, if so, reactivates the tick.

If the governor predicts a long idle, and the idle period turns out to be long, the governor "wins": the CPU will enter a deep idle state and power will be saved. But if the governor predicts long idle and the period turns out to be short, the governor "loses" because the costs of entering a deep idle state are not repaid by power savings over the short idle period. Worse, if the governor predicts a short idle period, it loses regardless of the actual idle duration: if the actual duration is long, potential power savings have been missed out on, and if it's short, the costs of stopping and restarting the tick have been paid needlessly. Or to put it another way, because stopping and starting the tick have a cost, there is no point in stopping the tick if the governor is going to predict a short idle.

Wysocki considered trying to redesign the governor to work around this, but concluded that the essential problem is that the tick is stopped before the governor is invoked, thus before the recommended idle state is known. He therefore reworked the idle loop for kernel 4.17 so that the decision about stopping the tick is taken after the governor has made its recommendation of the idle state. If the recommendation is for a long idle, the tick is stopped so as not to wake the CPU prematurely. If the recommendation is for a short idle, the tick is left on to avoid paying the cost of turning it off. That means the tick is also a safety net that will wake the CPU in the event that the idle turns out to be longer than predicted and give the governor another chance to get it right.

When the idled CPU is woken by an interrupt, whether from the tick that was left running or by some other event, the scheduler immediately makes a decision about whether there's work to do. If there is, the tick is restarted if need be; but if there is not, the governor is immediately re-invoked. Since that means the governor can now be invoked both when the tick is running and when it is stopped, the governor had to be reworked to take this into account.

Re-examining the win/loss table from earlier, Wysocki expects things to be improved by this rework. If long idle is predicted, the tick is still stopped, so nothing changes; we win if the actual idle is long, and lose if it's short. But if short idle is predicted, we're better off: if the actual idle is short, we've saved the cost of stopping and restarting the tick, and if the actual idle is long, the unstopped timer will wake us up and give us another bite at the prediction cherry.

Since game theory is no substitute for real-world data, Wysocki tested this on a number of systems. The graph above is characteristic of all the systems tested and shows power consumption against time on a system that is idle. The green line is with the old idle loop, the red is with the new: power consumption is less under the new scheme, and moreover it is much more predictable than before. Not all CPUs tested showed as large a gap between the green and red lines, but all showed a flat red line beneath a bumpy green one. As Wysocki put it, this new scheme predicts short idles less often than the old scheme did, but it is right about them being short more often.

In response to a question from the audience, Wysocki said that the work is architecture-independent. Intel CPUs will benefit from it particularly, because they have a comparatively large array of idle states from which the governor may select, giving the governor the best chance of doing well if it predicts correctly; but ARM CPUs, for example, will also benefit.

A 20% drop in idle power consumption may seem small as victories go, but it's not. Any system that wants to be able to cope reasonably well with peak loads will need spare capacity in normal operation, which will manifest as idle time. The graph above shows CPU usage on my mail/talk/file-transfer/VPN/NTP/etc. server over the past year; the bright yellow is idle time. Saving 20% of that power will please my co-location provider very much indeed, and it's good for the planet, too.

[We would like to thank LWN's travel sponsor, The Linux Foundation, for assistance with travel funding for Kernel Recipes.]

Comments (45 posted)

New AT_ flags for restricting pathname lookup

System calls like openat() have access to the entire filesystem — or, at least, that part of the filesystem that exists in the current mount namespace and which the caller has the permission to access. There are times, though, when it is desirable to reduce that access, usually for reasons of security; that has proved to be especially true in many container use cases. A new patch set from Aleksa Sarai has revived an old idea: provide a set of AT_ flags that can be used to control the scope of a given pathname lookup operation.

There have been previous attempts at restricting pathname lookup, but none of them have been merged thus far. David Drysdale posted an O_BENEATH option to openat() in 2014 that would require the eventual target to be underneath the starting directory (as provided to openat()) in the filesystem hierarchy. More recently, Al Viro suggested AT_NO_JUMPS as a way of preventing lookups from venturing outside of the current directory hierarchy or the starting directory's mount point. Both ideas have attracted interest, but neither has yet been pushed long or hard enough to make it into the mainline.

Sarai's venture into this territory takes the form of several new AT_ flags that can be used with system calls like openat():

• AT_BENEATH would, similar to O_BENEATH, prevent the pathname lookup from moving above the starting point in the filesystem hierarchy. So, as a simple example, an attempt to open ../foo would be blocked. This option does allow the use of ".." in a pathname as long as the result remains below the starting point, though, so opening foo/../bar would work.
• AT_XDEV prevents the lookup from crossing a mount-point boundary in either the upward or downward direction.
• AT_NO_PROCLINK prevents the following of symbolic links found in the /proc hierarchy; in particular, it is aimed at the links found under fd/ in any specific process's directory.
• AT_NO_SYMLINK prevents following any symbolic links at all, including those blocked by AT_NO_PROCLINK.
• AT_THIS_ROOT performs the equivalent of a chroot() call (to the starting directory) prior to the beginning of pathname lookup. This option, too, is meant to constrain lookups to the given directory hierarchy; it will also change how absolute symbolic links are interpreted.

There are numerous use cases for these new flags, but the driving force this time around would appear to be container workloads and, in particular, runtime systems for containers. Those systems often have to look inside a container and, perhaps, act on files within a container's directory hierarchy. If the container itself is compromised or otherwise malicious, it can attempt to play games with its filesystems to confuse the runtime system and gain access to the host.

This posting got a reception that was positive overall, but with a number of concerns about the details. For example, Jann Horn liked AT_BENEATH, but would rather that it forbade the use of ".." entirely, even if the result remains beneath the starting point. Doing so would help to block exploitation of various types of directory-traversal bugs, he said. Sarai responded that 37% of all the symbolic links on his system contained ".."; "this indicates to me that you would be restricting a large amount of reasonable resolutions because of this restriction". That said, he indicated a willingness to change the behavior if need be.

Horn also complained about the "footgun potential" of AT_THIS_ROOT which, he said, shares all of the security failings of chroot(). He described a scenario where a hostile container could force an escape by moving directories around: "If the root of your walk is below an attacker-controlled directory, this of course means that you lose instantly". A possible mitigation here would be to require the starting directory in AT_THIS_ROOT lookups to be a mount point; Sarai was amenable to making this change as well.

Horn, along with Andy Lutomirski, questioned the container-management use case; as Lutomirski put it: "Any sane container is based on pivot_root or similar, so the runtime can just do the walk in the container context". In this particular case, it turns out that part of the problem is the result of the fact that the container runtime in question is written in Go:

Since the system cannot use the relatively cheap ways to get into a container's context, it has to use an expensive workaround instead; this expense could be avoided if files could be opened with the new AT_ flags. Lutomirski responded that he is "not very sympathetic to the argument that 'Go's runtime model is incompatible with the simpler solution'". He proposed an alternative that might work in this setting without adding the new flags.

That alternative might work, but the fact remains that there are other use cases for restricting the scope of pathname lookups; that is why the idea continues to pop up on the kernel's mailing lists. And Lutomirski, too, agreed that some of the flags seem useful. Whether this implementation will be the one that manages to go all the way to the mainline remains to be seen, but it seems likely that, one of these years, the kernel will gain the ability to control lookups in a way similar to the one that has been proposed here.

Comments (23 posted)

Some numbers from the 4.19 development cycle

The release of 4.19-rc6 on September 30 is an indication that the 4.19 development cycle is heading toward its conclusion. Naturally, that means it's time to have a look at where the contributions for this cycle came from. The upheavals currently playing out in the kernel community do not show at this level, but there are some new faces to be seen in the top contributors this time around.

As of this writing, 13,657 non-merge changesets have found their way into the mainline for 4.19. That makes this development cycle the busiest since 4.15, but only by a little bit; the patch volume in recent cycles has been remarkably constant:

Cycle	Changesets
4.15	14,866
4.16	13,630
4.17	13,541
4.18	13,283
4.19	13,657	(so far)

The changes in 4.19 were contributed by 1,710 developers, again a typical number; 253 of those developers were contributing to the kernel for the first time. The last two development cycles both removed more lines of code from the kernel than they added; that trend has come to a screeching halt in 4.19, which added 307,000 lines.

The most active 4.19 developers were:

Most active 4.19 developers

By changesets John Whitmore 222 1.6% Chris Wilson 208 1.5% Gustavo A. R. Silva 205 1.5% Colin Ian King 178 1.3% Arnd Bergmann 155 1.1% Christoph Hellwig 132 1.0% Takashi Iwai 124 0.9% Todd Poynor 116 0.8% Bart Van Assche 110 0.8% Ville Syrjälä 104 0.8% Paul E. McKenney 101 0.7% Michael Straube 101 0.7% Brian Foster 90 0.7% Hans de Goede 86 0.6% Jason Gunthorpe 86 0.6% Boris Brezillon 85 0.6% Geert Uytterhoeven 83 0.6% Jerome Brunet 79 0.6% Jakub Kicinski 78 0.6% YueHaibing 77 0.6%

By changed lines Jeykumar Sankaran 32138 4.8% Richard Fitzgerald 14390 2.2% Jason Cooper 11415 1.7% Steven J. Hill 10008 1.5% Stanislaw Gruszka 8686 1.3% Darrick J. Wong 8396 1.3% Christoph Hellwig 8366 1.3% Simon Que 8083 1.2% Jerome Brunet 7702 1.2% Jiri Pirko 6597 1.0% Gao Xiang 6464 1.0% Jason Gunthorpe 6333 1.0% Rob Clark 6220 0.9% Lorenzo Bianconi 6032 0.9% Chris Wilson 5970 0.9% Linus Walleij 5642 0.9% Srinivas Kandagatla 5170 0.8% Benjamin Herrenschmidt 5150 0.8% Jordan Crouse 5114 0.8% David Lechner 5063 0.8%

The ranks of the top contributors include some new names this time around. John Whitmore's work was entirely focused on improving two Realtek drivers in the staging tree. Chris Wilson made many changes to the i915 graphics driver, Gustavo A. R. Silva and Colin Ian King made small cleanups all over the tree, and Arnd Bergmann made significant fixes all over, many as part of the larger year-2038 readiness effort.

On the "lines changed" side, Jeykumar Sankaran added a graphics driver for SDM845 chipsets. Richard Fitzgerald added support for some Cirrus Logic codecs, Jason Cooper removed the unloved Skein and Threefish crypto algorithms from the staging tree, Steven Hill cleaned up the MIPS Octeon architecture code, and Stanislaw Gruszka contributed the MediaTek mt76x0 driver.

Work on 4.19 was supported by a minimum of 230 employers, the most active of which were:

Most active 4.19 employers

By changesets Intel 1294 9.5% (None) 1180 8.6% Red Hat 970 7.1% IBM 674 4.9% (Unknown) 662 4.8% Linaro 604 4.4% Mellanox 561 4.1% AMD 546 4.0% Google 541 4.0% SUSE 495 3.6% Huawei Technologies 390 2.9% (Consultant) 309 2.3% Renesas Electronics 294 2.2% Bootlin 291 2.1% ARM 272 2.0% Oracle 250 1.8% Linux Foundation 235 1.7% Canonical 225 1.6% NXP Semiconductors 204 1.5% Code Aurora Forum 190 1.4%

By lines changed (None) 56201 8.5% Code Aurora Forum 53644 8.1% Intel 52937 8.0% Red Hat 44222 6.7% Mellanox 35693 5.4% Linaro 35591 5.4% IBM 26092 3.9% Google 24996 3.8% AMD 20602 3.1% (Unknown) 19136 2.9% Huawei Technologies 17230 2.6% (Consultant) 16199 2.4% Cirrus Logic 14565 2.2% SUSE 13685 2.1% Cavium 13338 2.0% Oracle 13309 2.0% BayLibre 11854 1.8% ARM 10897 1.6% Renesas Electronics 10703 1.6% Facebook 10082 1.5%

One thing that jumps out is the amount of work that came from developers who were not working for anybody else. That number is still low by long-term historic standards (it was 12% for 3.0, for example), but is higher than it has been in recent times. There were 116 developers known to be working on their own time, or just under 7% of the developers working on the kernel; they contributed 8.5% of the total work.

With regard to testing and reviewing, the numbers this time around look like this:

Test and review credits in 4.19

Tested-by Pavel Machek 40 5.5% Andrew Bowers 27 3.7% Alexandre Courbot 26 3.6% Arnaldo Carvalho de Melo 26 3.6% Joel Stanley 23 3.2% Shakeel Butt 17 2.4% Neil Brown 15 2.1% Hans de Goede 14 1.9% Tony Brelinski 13 1.8% Stan Johnson 12 1.7% Jiri Kosina 11 1.5% Song Liu 10 1.4% Randy Dunlap 10 1.4% Peter Rosin 9 1.2% Matthias Kaehlcke 7 1.0% Lucas Stach 7 1.0% Hanjun Guo 7 1.0% Ganapatrao Kulkarni 7 1.0% Dave Penkler 7 1.0% Aaron Brown 7 1.0%

Reviewed-by Rob Herring 185 3.8% Darrick J. Wong 144 2.9% Christoph Hellwig 134 2.7% Christian König 101 2.1% Andrew Morton 91 1.8% Alex Deucher 85 1.7% Geert Uytterhoeven 77 1.6% Simon Horman 66 1.3% David Sterba 63 1.3% Boris Brezillon 62 1.3% Tony Cheng 61 1.2% Andy Shevchenko 57 1.2% Tvrtko Ursulin 57 1.2% Daniel Vetter 53 1.1% Quentin Monnet 53 1.1% Ville Syrjälä 52 1.1% Rodrigo Vivi 49 1.0% Harry Wentland 49 1.0% Fabio Estevam 49 1.0%

Of the 13,657 patches merged for 4.19, 659 carried Tested-by tags — about 5% of the total. 4,085 (30%) carried Reviewed-by tags. The following chart shows the trends in the use of these tags in recent years:

As can be seen in this plot, the percentage of patches carrying Tested-by tags is at best flat over the 4.x series (which began in 2015). If one looks further back to 3.1 in late 2011, though, 3.6% of patches carried those tags, so there has been a bit of growth over that period. Reviewed-by tags, instead, are clearly appearing in more patches over time as more subsystems require them. That number, too, is up significantly from 3.1, where only 8.7% of patches had such tags. Kernel developers may be slow to adopt change, but some things do eventually change over time.

What doesn't seem to change is that the kernel-development machine continues to crank out releases integrating vast amounts of change on a predictable basis. The community is in a period of change in a number of ways, but it is to be expected that this record, which has held steady for many years now, will continue into the future.

Comments (4 posted)

The modernization of PCIe hotplug in Linux

PCI Express hotplug has been supported in Linux for fourteen years. The code, which is aging, is currently undergoing a transformation to fit the needs of contemporary applications such as hot-swappable flash drives in data centers and power-manageable Thunderbolt controllers in laptops. Time for a roundup.

The initial PCI specification from 1992 had no provisions for the addition or removal of cards at runtime. In the late 1990s and early 2000s, various proprietary hotplug controllers, as well as the vendor-neutral standard hotplug controller, were conceived and became supported by Linux through drivers living in drivers/pci/hotplug. PCI Express (PCIe), instead, supported hotplug from the get-go in 2002, but its embodiments have changed over time. Originally intended to hot-swap PCIe cards in servers or ExpressCards in laptops, today it is commonly used in data centers (where NVMe flash drives need to be swapped at runtime) and by Thunderbolt (which tunnels PCIe through a hotpluggable chain of converged I/O switches, together with other protocols such as DisplayPort).

Threaded interrupts

Linux's PCIe hotplug driver, called pciehp, was introduced in 2004 by Dely Sy. The first major cleanup and rework was carried out by Kenji Kaneshige, who stopped doing this work in 2011. After that, contributions were largely confined to duct-taping over the driver's remaining weaknesses, in particular its event handling.

Threaded interrupts are the predominant interrupt-handling pattern in the kernel and a cornerstone of realtime Linux but, unfortunately, they were introduced after Kaneshige's rework had concluded. pciehp's hard interrupt handler therefore identified which event(s) had occurred, such as "link-up" or "link-down", and queued a work item for each of them. The problem with this approach was that, by the time the work item was executed, the link status may well have changed again. Moreover, if the link flipped more quickly than the hard interrupt handler ran, unbalanced link-up and link-down events would be detected. Finally, the possibility of multiple in-flight work items and how they interact made it difficult to reason about the event-handling code's correctness. Recently, Bjorn Helgaas (who is the PCI maintainer) referred to pciehp's event handling as "baroque". A point was reached where duct-taping was no longer an option and a fundamental rethink of the driver became unavoidable.

For Linux 4.19, I converted pciehp to threaded interrupt handling; events are now collected by the hard interrupt handler for later consumption by the interrupt thread. The detection of whether a link change is a link-up or link-down is deferred until the handling of the event by the interrupt thread to avoid handling stale events. The new approach can deal with a quick series of events (such as a link-down rapidly followed by a link-up) and tolerates link flips during bring-up of the slot, which may be caused by sketchy board layout or electromagnetic interference. The patch set also included a fair number of bug fixes and cleanups so, overall, robustness and reliability should improve noticeably. Follow-up patches queued for 4.20 shave off close to 500 lines from pciehp and other hotplug drivers, resulting in a further simplification and rationalization.

Runtime power management

Linux 4.19 will also add the ability to runtime suspend PCIe hotplug ports. This is necessary to power down Thunderbolt controllers, which show up in the operating system as a PCIe upstream port and multiple PCIe downstream ports (with hotplugged devices appearing below the latter once a tunnel has been established). Before a controller can power down, all its PCIe ports need to runtime suspend. Linux has been able to runtime suspend the upstream port since 4.8, but could not runtime suspend the downstream ports before 4.19.

Runtime suspending a Thunderbolt PCIe port does not itself result in any saved power: the port will encapsulate and decapsulate PCIe packets for transport over the converged I/O switch and consume energy as long as that switch is powered. However, Linux's power-management model requires that all child devices must suspend before their parent can. By runtime suspending all of the Thunderbolt controller's ports, its parent, a root port, is allowed to suspend which, in turn, triggers power-down of the controller through ACPI platform methods. Powering down the controller does result in a significant power saving of about 1.5W.

Put another way, runtime suspending Thunderbolt PCIe ports is done to satisfy the needs of Linux's hierarchical power-management model. A single Thunderbolt PCIe port consumes the same amount of energy regardless whether its PCI power state is D0 (full power) or D3hot (suspended), but when all ports are runtime suspended, the controller as a whole can be powered down. (Powering down Thunderbolt controllers on Macs will need further patches that may appear in the 4.21 time frame.)

An interesting detail is the handling of hotplug events that occur while a PCIe hotplug port is runtime suspended: if its parents are runtime suspended as well, the port is inaccessible. So it cannot signal the interrupt in-band, and the kernel can't react to it or even determine the type of event until the parents are runtime resumed. There are two known ways for hardware to deal with this.

The first is in accordance with the PCIe specification: the hotplug port signals a power-management event (PME), which may happen out-of-band through a means provided by the platform, such as a general-purpose I/O pin (a WAKE# signal in PCIe terminology). The PME causes wakeup of the hierarchy below the Thunderbolt host controller, whereupon the hotplug port becomes accessible. This method is known to be used on Lenovo and Dell laptops with Thunderbolt 3 and allows controllers to power down even if devices are attached. Mika Westerberg has submitted patches for 4.20 to support it.

The second method is nonstandard: the Thunderbolt hardware knows which tunnels are currently established and can therefore convert a hotplug event occurring at the converged I/O layer to a hotplug event occurring at the overlaid PCIe layer. Thus, when a device is attached or removed, an interrupt is magically received from the affected PCIe port regardless whether it and its parents are in D3hot. This method is known to be used on Apple Macs with Thunderbolt 1 and requires that the Thunderbolt host controller remains powered up as long as devices are attached. Support for it was added in 4.19.

Runtime power management is currently not enabled for non-Thunderbolt hotplug ports as they are known to cause issues such as non-maskable interrupts when put into D3hot. Vendors may pass "pcie_port_pm=force" on the command line to validate their hotplug ports for runtime suspend support and perhaps the feature can be enabled by default at a later point.

Surprise removal

The original PCIe specification defined a standard usage model that included a manually operated retention latch to hold a card in place and an attention button to request bring-down of a slot from the operating system. But contemporary implementations often omit those elements and exclusively use surprise removal of devices.

When a device is yanked out, pciehp asks its driver to unbind, then brings down the slot. But, until that happens, read requests to the device will time out after (typically) 17ms, and return a fabricated "all ones" response. The timeouts slow down the requesting task and, if the fabricated response is mistaken for real data, the task may crash or get stuck in an infinite loop. Drivers therefore need to validate data read from a device and, in particular, check for all ones in cases when that is not a valid response. A common idiom is to call pci_device_is_present(), which reads the vendor ID register and checks if it is all ones. However that is not a panacea; if a PCIe uncorrectable error occurs, the device may likewise respond with all ones, but revert to valid responses if the error can be recovered. Moreover, all ones is returned for unsupported requests or read requests that are inside a bridge's address window but outside any of the target device's base address registers (BARs). The only entity that can identify removal authoritatively and unambiguously is pciehp.

Many drivers — and even the PCI core — do not check every read for an all-ones response. Engineers working on Facebook's "Lightning" storage architecture had to learn this the hard way [YouTube]. Surprise-removing an entire array of NVMe drives took many seconds and occasionally caused machine-check exceptions. It was so slow that the driver would find itself talking with a new device plugged into that slot before the processing of the previous removal had completed. One of the outcomes was a patch set by Keith Busch in Linux 4.12 to have pciehp set a flag on surprise-removed devices and skip access to them in a few strategic places in the PCI core. This was sufficient to speed up removal to microseconds. In particular, pci_device_is_present() is short-circuited to return false if the flag is set. Before, if the device was quickly swapped with another one, the function incorrectly returned true for the removed device once the vendor ID of the new device became readable.

At Benjamin Herrenschmidt's behest, another patch by Busch is now queued for 4.20 to unify the flag with the error state of a PCI device. The error state allows distinguishing whether the device is temporarily inaccessible after an unrecoverable error but has a chance to come back, or whether it has failed permanently. Drivers can either check the error_state member in struct pci_dev directly or call pci_channel_offline() to determine the accessibility of a device.

However, Helgaas has voiced misgivings about the flag in general. For one, the flag is set asynchronously, so there is a latency between the device being removed and the flag being set. Driver authors need to be wary that, even if the device seems present per the flag, it may no longer be there. Conversely, if set, the flag does provide a definitive indication that any further device access is futile and can be skipped. The flag therefore does not relieve driver authors from validating responses from the device but, once set, it serves as a cache and avoids ambiguous vendor ID checks. In short, the problem is mitigated but not solved perfectly. A perfect solution seems nearly impossible though; we cannot acquire a mutex on the user to prevent them from yanking a device and we cannot check for a presence change after every device access for performance reasons. Austin Bolen pointed out that a new PCIe extension called "root port programmed I/O" allows for synchronous exception handling of failed device accesses and thus for a seemingly perfect solution, but "this feature won't be available in products for some time and is optional".

A second concern Helgaas has with the flag is that it may obscure bugs that occur upon surprise removal but which become less visible when the flag is set, complicating their discovery and resolution. For example, a search for the advanced error recovery (AER) capability on device removal caused numerous configuration-space accesses and, before introduction of the flag, was noticeable through a significant slowdown upon surprise removal. But the proper solution was to cache the position of the AER capability, rather than paper over the issue by skipping the configuration accesses using the flag.

Error-handling integration

The move to threaded interrupts also eases integrating pciehp with the handling of PCIe uncorrectable errors: when such an error occurs at or below a hotplug port, it may cause a link-down event as a side effect. But, sometimes the error can be recovered through software, by performing a secondary bus reset, for example. In this case, it is undesirable for pciehp to react to the link-down event by unbinding the attached devices from their drivers and bringing down the slot. Rather, it should wait to see whether the error can be recovered and ignore the link event if so. To this end, Busch and Sinan Kaya are currently working on patches to tie in pciehp with the AER and downstream port containment service drivers.

Moving BARs

A PCIe device is allocated memory ranges for memory-mapped I/O that are configured in the device's BARs. The memory ranges are usually predefined by the BIOS, but Linux may move them around on enumeration. Bridges upstream of a PCI device have their address windows configured in such a way that transactions targeting a device's BAR are routed correctly.

When devices are hot-added, their memory requirements may not fit into the windows of their upstream bridges, necessitating a reorganization of resources: adjacent BARs need to be moved and bridge windows adjusted. MacOS gained this capability in 2013 for improved Thunderbolt support and calls it "PCIe pause". Drivers are told to pause I/O to affected devices; on unpause, the BARs may have changed and drivers are required to reconfigure their devices and update internal data structures as necessary.

Sergey Miroshnichenko recently submitted initial patches to bring moving of BARs to Linux, to positive reactions. The patches use existing callbacks to pause access to a device before a PCI reset and restart access afterward. Drivers will have to opt into BAR movement. MacOS supports reallocation of PCI bus numbers and message-signaled interrupts in addition to BARs; Miroshnichenko is looking into adding that in a future revision of the patch set.

In summary

The SD Card 7.0 specification announced in June is based on PCIe and NVMe and may greatly extend the usage of PCIe hotplug in consumer electronics devices. The ongoing activities in the kernel therefore seem to come at the right time and promise to yield an up-to-par PCIe hotplug infrastructure over the coming releases.

Comments (9 posted)

Control Flow Integrity in the Android kernel (Android Developers)

The Android Developers Blog describes the control-flow integrity work that is shipping on the Pixel 3 handset. "LLVM's CFI implementation adds a check before each indirect branch to confirm that the target address points to a valid function with a correct signature. This prevents an indirect branch from jumping to an arbitrary code location and even limits the functions that can be called. As C compilers do not enforce similar restrictions on indirect branches, there were several CFI violations due to function type declaration mismatches even in the core kernel that we have addressed in our CFI patch sets for kernels 4.9 and 4.14."

Comments (15 posted)

Security quotes of the week

— Jordan Robertson and Michael Riley in Bloomberg Businessweek

— Brian Krebs

Comments (3 posted)

Kernel release status

The current development kernel is 4.19-rc7, released on October 7. "Given the current rate of change, and looking at the travel/conference schedule happening this month, it seems like we will be having a -rc8 just to be sure 4.19 is solid as well as not having to be in the middle of a merge window during a conference week".

Stable updates: 4.18.12, 4.14.74, and 4.9.131 were released on October 4, followed by 4.18.13, 4.14.75, 4.9.132, and 4.4.160 on October 10.

Comments (none posted)

Amit: How new-lines affect the Linux kernel performance

Nadav Amit decided to dig into why some small kernel functions were not being inlined by GCC; the result is a detailed investigation into how these things can go wrong. "Ignoring the assembly shenanigans that this code uses, we can see that in practice it generates a single ud2 instruction. However, the compiler considers this code to be 'big' and consequently oftentimes does not inline functions that use WARN() or similar functions. The reason turns to be the newline characters (marked as '\n' above). The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. It therefore tries to estimate its size based on newline characters and statement separators (';' on x86)."

Comments (31 posted)

Gregg: bpftrace (DTrace 2.0) for Linux 2018

Brendan Gregg introduces the bpftrace tracing tool. "bpftrace was created as an even higher-level front end for custom ad-hoc tracing, and can serve a similar role as DTrace. We've been adding bpftrace features as we need them, not just because DTrace had them. I can think of over a dozen things that DTrace can do that bpftrace currently cannot, including custom aggregation printing, shell arguments, translators, sizeof(), speculative tracing, and forced panics".

Comments (16 posted)

Distribution quotes of the week

— Antoine Beaupré

— Daniil Baturin

Comments (none posted)

Development quotes of the week

— Glyn Moody

— Simon Heath

Comments (12 posted)

Microsoft joins LOT Network, helping protect developers against patent assertions

Microsoft has announced that it has joined the LOT Network, which is an organization set up to help thwart patent trolls by licensing any member's patents to all members if they end up in the hands of a troll. "What does all of this mean for you if you’re a software developer or in the technology business? It means that Microsoft is taking another step to help stop patents from being asserted against you by companies running aggressive monetization campaigns. It also means that Microsoft is aligning with other industry leaders on this topic and committing to do more in the future to address IP risk. By joining the LOT network, we are committing to license our patents for free to other members if we ever transfer them to companies in the business of asserting patents. This pledge has immediate value to the nearly 300 members of the LOT community today, which covers approximately 1.35 million patents."

Comments (17 posted)

Microsoft joins Open Invention Network

Microsoft has announced that it has joined the Open Invention Network (OIN). "We know Microsoft’s decision to join OIN may be viewed as surprising to some, as it is no secret that there has been friction in the past between Microsoft and the open source community over the issue of patents. For others who have followed our evolution as a company, we hope this will be viewed as the next logical step for a company that is listening to its customers and is firmly committed to Linux and other open source programs."

Comments (19 posted)

• DistroWatch Weekly (October 8)

• Lunar Linux Weekly News (October 5)

• openSUSE Tumbleweed Review of the Week (October 5)

• Reproducible Builds Weekly Report (October 8)

• Tails Report (September)

• Ubuntu Weekly Newsletter (October 6)

• Emacs News (October 8)

• These Weeks in Firefox (October 10)

• What's cooking in git.git (October 10)

• LibreOffice monthly recap (October 4)

• LLVM Weekly (October 8)

• LXC/LXD/LXCFS Weekly Status (October 9)

• OCaml Weekly News (October 9)

• OpenStack Technical Committee Status Update (October 8)

• Perl Weekly (October 8)

• Weekly changes in and around Perl 6 (October 8)

• PostgreSQL Weekly News (October 7)

• Python Weekly Newsletter (October 4)

• Ruby Weekly News (October 4)

• This Week in Rust (October 9)

• Wikimedia Tech News (October 8)

• Fedora Council minutes (October 10)

• Fedora FESCO meeting minutes (October 8)

CFP Deadlines: October 11, 2018 to December 10, 2018

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

Deadline	Event Dates	Event	Location
October 22	December 3 December 4	DPDK Summit North America 2018	San Jose, CA, USA
October 26	January 25 January 27	DevConf.cz	Brno, Czechia
October 31	March 7 March 10	SCALE 17x	Pasadena, CA, USA
October 31	November 24 November 25	DebUtsav Kochi 2018	Kerala, India
November 3	February 2 February 3	FOSDEM	Brussels, Belgium
November 9	March 23 March 24	LibrePlanet	Cambridge, MA, USA
November 15	February 25 February 26	Vault Linux Storage and Filesystems Conference	Boston, MA, USA
November 16	March 19 March 21	PGConf APAC	Singapore, Singapore
November 18	January 21	LCA2019 System Administration Miniconf	Christchurch, New Zealand
November 30	December 1	Central Pennsylvania Open Source Conference	Lancaster, PA, USA

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

SFLC 2018 Annual Conference at Columbia Law School

Software Freedom Law Center's annual conference will take place November 2 in New York, NY. The schedule has been announced.

Full Story (comments: none)

Events: October 11, 2018 to December 10, 2018

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

Date(s)	Event	Location
October 10 October 12	PyCon ZA 2018	Johannesburg, South Africa
October 12 October 13	Ohio LinuxFest 2018	Columbus, OH, USA
October 15 October 18	Tcl/Tk Conference	Houston, TX, USA
October 18 October 19	Osmocom Conference 2018	Berlin, Germany
October 20 October 21	OSS Víkend	Košice, Slovakia
October 21 October 23	All Things Open	Raleigh, NC, USA
October 22 October 24	Open Source Summit Europe	Edinburgh, UK
October 22 October 24	Embedded Linux Conference Europe	Edinburgh, UK
October 23 October 26	PostgreSQL Conference Europe 2018	Lisbon, Portugal
October 24	Proxtalks 2018	Frankfurt am Main, Germany
October 24 October 26	KVM Forum 2018	Edinburgh, UK
October 24 October 26	PyCon.DE 2018	Karlsruhe, Germany
October 25	Tracing Summit 2018	Edinburgh, UK
October 25	Real-Time Summit	Edinburgh, UK
October 25 October 26	Linux Security Summit	Edinburgh, UK
October 25 October 26	GStreamer Conference 2018	Edinburgh, Scotland, UK
October 25 October 26	Free Software and Open Source Symposium	Toronto, Canada
October 27 October 28	Sonoj Convention	Cologne, Germany
October 29 October 30	OpenWrt Summit	Lisbon, Portugal
October 29 October 31	LISA18	Nashville, TN, USA
November 2	Software Freedom Law Center’s Fall Conference	New York, NY, USA
November 3 November 4	OpenFest 2018	Sofia, Bulgaria
November 5 November 7	MesosCon 2018	New York, NY, USA
November 5 November 8	Open Source Monitoring Conference	Nuremberg, Germany
November 8 November 11	QtCon Brazil 2018	São Paulo, Brazil
November 8	Open Source Camp	Nürnberg, Germany
November 9	August Penguin Conference 2018	Tel Aviv, Israel
November 9 November 13	PyCon Canada 2018	Toronto, Canada
November 9 November 10	Seattle GNU/Linux	Seattle, WA, USA
November 12 November 15	Linux Kernel Summit	Vancouver, Canada
November 12	RabbitMQ Summit 2018	London, UK
November 12	Ceph Day Berlin	Berlin, Germany
November 13 November 15	Linux Plumbers Conference	Vancouver, BC, Canada
November 13 November 15	OpenStack Summit	Berlin, Germany
November 14 November 15	KubeCon+CloudNativeCon China	Shanghai, China
November 15	NLUUG (fall conference)	Utrecht, The Netherlands
November 19 November 20	DevOpsDays Galway	Galway, Ireland
November 24 November 25	DebUtsav Kochi 2018	Kerala, India
December 1	Central Pennsylvania Open Source Conference	Lancaster, PA, USA
December 3 December 4	DPDK Summit North America 2018	San Jose, CA, USA
December 3 December 4	LinuxLab	Florence, Italy
December 7	PGDay Down Under 2018	Melbourne, Australia
December 8	Open Source Conference 2018	Fukuoka, Japan

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

Videos from Open Source Firmware Conference

The Open Source Firmware Conference was held September 12-15. Videos from the conference are available on YouTube.

Comments (none posted)

Videos from the GNU Tools Cauldron

The 2018 GNU Tools Cauldron was held in early September; videos of the talks from that event are now available. There is a wide range of discussions covering various aspects of the toolchain, including GCC, GDB, glibc, and more.

Comments (none posted)

Alert summary October 4, 2018 to October 10, 2018

Dist.	ID	Release	Package	Date
Arch Linux	ASA-201810-6		firefox	2018-10-04
Arch Linux	ASA-201810-7		git	2018-10-09
Arch Linux	ASA-201810-8		patch	2018-10-10
Arch Linux	ASA-201810-5		python-django	2018-10-03
CentOS	CESA-2018:2881	C6	firefox	2018-10-09
CentOS	CESA-2018:2884	C7	firefox	2018-10-09
CentOS	CESA-2018:2892	C6	glusterfs	2018-10-09
CentOS	CESA-2018:2846	C6	kernel	2018-10-09
CentOS	CESA-2018:2898	C6	nss	2018-10-09
Debian	DLA-1534-1	LTS	adplug	2018-10-07
Debian	DLA-1532-1	LTS	dnsmasq	2018-10-04
Debian	DSA-4310-1	stable	firefox-esr	2018-10-03
Debian	DLA-1533-1	LTS	git	2018-10-05
Debian	DSA-4311-1	stable	git	2018-10-05
Debian	DLA-1530-1	LTS	imagemagick	2018-10-03
Debian	DLA-1529-1	LTS	kernel	2018-10-04
Debian	DSA-4313-1	stable	kernel	2018-10-08
Debian	DLA-1531-1	LTS	linux-4.9	2018-10-04
Debian	DLA-1540-1	LTS	net-snmp	2018-10-09
Debian	DLA-1535-1	LTS	php-horde	2018-10-08
Debian	DLA-1536-1	LTS	php-horde-core	2018-10-08
Debian	DLA-1537-1	LTS	php-horde-kronolith	2018-10-08
Debian	DLA-1539-1	LTS	samba	2018-10-08
Debian	DLA-1538-1	LTS	tinc	2018-10-08
Debian	DSA-4312-1	stable	tinc	2018-10-08
Fedora	FEDORA-2018-6c0aeafdfa	F28	firefox	2018-10-05
Fedora	FEDORA-2018-381ab64b59	F28	haproxy	2018-10-03
Fedora	FEDORA-2018-ddbaca855e	F28	kernel-headers	2018-10-09
Fedora	FEDORA-2018-3e9f26489b	F27	lcms2	2018-10-04
Fedora	FEDORA-2018-9a09435935	F27	liblouis	2018-10-07
Fedora	FEDORA-2018-70fac49405	F28	liblouis	2018-10-07
Fedora	FEDORA-2018-3b14abc9b0	F27	libmad	2018-10-05
Fedora	FEDORA-2018-4f9f4d26f0	F28	libmad	2018-10-05
Fedora	FEDORA-2018-edf90410ea	F27	mediawiki	2018-10-07
Fedora	FEDORA-2018-e022ecbc52	F28	mediawiki	2018-10-07
Fedora	FEDORA-2018-d0dff2abaa	F28	opensc	2018-10-05
Fedora	FEDORA-2018-1f64819623	F27	php-horde-Horde-Core	2018-10-07
Fedora	FEDORA-2018-f4558a5180	F28	php-horde-Horde-Core	2018-10-07
Fedora	FEDORA-2018-1de045298c	F27	php-horde-horde	2018-10-07
Fedora	FEDORA-2018-520062dcb8	F28	php-horde-horde	2018-10-07
Fedora	FEDORA-2018-d280e35281	F27	php-horde-kronolith	2018-10-07
Fedora	FEDORA-2018-1c9f3f4d9e	F28	php-horde-kronolith	2018-10-07
Fedora	FEDORA-2018-187e212568	F27	php-tcpdf	2018-10-04
Fedora	FEDORA-2018-f1ca41a1a6	F28	php-tcpdf	2018-10-04
Fedora	FEDORA-2018-69cce46328	F27	rust	2018-10-05
Fedora	FEDORA-2018-0071ad34f4	F28	rust	2018-10-05
Fedora	FEDORA-2018-3d187b1a5b	F27	udisks2	2018-10-04
Gentoo	201810-04		imagemagick	2018-10-06
Gentoo	201810-03		openssh	2018-10-06
Gentoo	201810-02		sox	2018-10-06
openSUSE	openSUSE-SU-2018:3014-1	15.0	ImageMagick	2018-10-05
openSUSE	openSUSE-SU-2018:3001-1	15.0 42.3	bitcoin	2018-10-04
openSUSE	openSUSE-SU-2018:2996-1	15.0 42.3	firefox	2018-10-04
openSUSE	openSUSE-SU-2018:3038-1	15.0	ghostscript	2018-10-05
openSUSE	openSUSE-SU-2018:3036-1	42.3	ghostscript	2018-10-05
openSUSE	openSUSE-SU-2018:3035-1	15.0 42.3	gitolite	2018-10-05
openSUSE	openSUSE-SU-2018:3057-1	15.0	java-1_8_0-openjdk	2018-10-06
openSUSE	openSUSE-SU-2018:3071-1	15.0	kernel	2018-10-08
openSUSE	openSUSE-SU-2018:3012-1	15.0	libX11	2018-10-05
openSUSE	openSUSE-SU-2018:3015-1	15.0	openssl-1_0_0	2018-10-05
openSUSE	openSUSE-SU-2018:3013-1	15.0	openssl-1_1	2018-10-05
openSUSE	openSUSE-SU-2018:3005-1	15.0	otrs	2018-10-04
openSUSE	openSUSE-SU-2018:3056-1	42.3	php5	2018-10-06
openSUSE	openSUSE-SU-2018:3062-1	15.0	php7	2018-10-06
openSUSE	openSUSE-SU-2018:3052-1	15.0	python	2018-10-06
openSUSE	openSUSE-SU-2018:2998-1	42.3	texlive	2018-10-04
openSUSE	openSUSE-SU-2018:3051-1	15.0 42.3	thunderbird	2018-10-06
openSUSE	openSUSE-SU-2018:3054-1	15.0	tomcat	2018-10-06
openSUSE	openSUSE-SU-2018:3043-1	42.3	unzip	2018-10-05
Oracle	ELSA-2018-2884	OL7	firefox	2018-10-08
Oracle	ELSA-2018-2884	OL7	firefox	2018-10-09
Oracle	ELSA-2018-2892	OL6	glusterfs	2018-10-09
Oracle	ELSA-2018-2846	OL6	kernel	2018-10-09
Oracle	ELSA-2018-2898	OL6	nss	2018-10-09
Red Hat	RHSA-2018:2881-01	EL6	firefox	2018-10-08
Red Hat	RHSA-2018:2884-01	EL7	firefox	2018-10-08
Red Hat	RHSA-2018:2892-01	EL6	glusterfs	2018-10-09
Red Hat	RHSA-2018:2846-01	EL6	kernel	2018-10-09
Red Hat	RHSA-2018:2898-01	EL6	nss	2018-10-09
Red Hat	RHSA-2018:2887-01	EL7	qemu-kvm-rhev	2018-10-09
Red Hat	RHSA-2018:2882-01	SCL	rh-haproxy18-haproxy	2018-10-08
Scientific Linux	SLSA-2018:2881-1	SL6	firefox	2018-10-08
Scientific Linux	SLSA-2018:2884-1	SL7	firefox	2018-10-09
SUSE	SUSE-SU-2018:3072-1	SLE15	ImageMagick	2018-10-08
SUSE	SUSE-SU-2018:3082-1	SLE15	java-1_8_0-ibm	2018-10-09
SUSE	SUSE-SU-2018:3064-1	OS7 SLE12	java-1_8_0-openjdk	2018-10-08
SUSE	SUSE-SU-2018:3045-1	SLE15	java-1_8_0-openjdk	2018-10-05
SUSE	SUSE-SU-2018:3084-1	OS7 SLE12	kernel	2018-10-09
SUSE	SUSE-SU-2018:3088-1	SLE11	kernel	2018-10-09
SUSE	SUSE-SU-2018:3004-1	SLE12	kernel	2018-10-04
SUSE	SUSE-SU-2018:3083-1	SLE12	kernel	2018-10-09
SUSE	SUSE-SU-2018:3032-1	SLE12	kernel	2018-10-05
SUSE	SUSE-SU-2018:3073-1		kubernetes-salt, velum	2018-10-08
SUSE	SUSE-SU-2018:3081-1	SLE12	libxml2	2018-10-09
SUSE	SUSE-SU-2018:3080-1	SLE15	libxml2	2018-10-09
SUSE	SUSE-SU-2018:2991-1	OS7 SLE12	openslp	2018-10-04
SUSE	SUSE-SU-2018:3017-1	SLE12	php5	2018-10-05
SUSE	SUSE-SU-2018:3018-1	SLE11	php53	2018-10-05
SUSE	SUSE-SU-2018:3016-1	SLE15	php7	2018-10-05
SUSE	SUSE-SU-2018:3074-1	OS7 SLE12	postgresql10	2018-10-08
SUSE	SUSE-SU-2018:3002-1	SLE15	python	2018-10-04
SUSE	SUSE-SU-2018:3066-1	OS7 SLE12	qpdf	2018-10-08
SUSE	SUSE-SU-2018:3070-1	SLE12	soundtouch	2018-10-08
SUSE	SUSE-SU-2018:3068-1	SLE15	soundtouch	2018-10-08
SUSE	SUSE-SU-2018:3033-1	SLE12	texlive	2018-10-05
Ubuntu	USN-3783-1	18.04	apache2	2018-10-03
Ubuntu	USN-3784-1	14.04 16.04 18.04	apparmor	2018-10-04
Ubuntu	USN-3785-1	14.04 16.04 18.04	imagemagick	2018-10-04
Ubuntu	USN-3786-1	14.04 16.04	libxkbcommon	2018-10-08
Ubuntu	USN-3781-2	18.04	webkit2gtk	2018-10-10

Full Story (comments: none)