Welcome to the LWN.net Weekly Edition for November 2, 2023

This edition contains the following feature content:

• Implicit keyword arguments for Python: a debate of some syntactic sugar that would reduce the verbosity of some function calls.
• Better string handling for the kernel: is it time to finally move away from NUL-terminated strings?
• Deferred scheduling for user-space critical sections: a proposed scheduler extension to improve the performance of highly threaded applications.
• Some 6.6 development statistics: where the code in the 6.6 kernel came from.
• Rust code review and netdev: an impedance mismatch between the networking and Rust-for-Linux developers highlights the challenges of bringing a new language into the kernel.
• Help wanted at LWN: we are looking to hire a writer/editor; might that person be you?

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)

Implicit keyword arguments for Python

Python functions can use both positional and keyword arguments; the latter provide a certain level of documentation for an argument and its meaning, while allowing them to be given in any order in a call. But it is often the case that the name of the local variable to be passed is the same as the keyword, which can lead to overly repetitive argument lists, at least in some eyes. A recent proposal to shorten the syntax for calls with these duplicate names seems to be gaining some steam—a Python Enhancement Proposal (PEP) is forthcoming—though there are some who find it to be an unnecessary and unwelcome complication for the language.

Parameters and arguments

The parameter list of a Python function describes the names of its parameters; those parameters are matched up with the arguments that get passed in a call to the function. For example:

    def func(a, b, c=3, d=None):   # definition with four parameters
        pass

    func(1, b=42, c=9, d=6)        # a call with four arguments

But it is not infrequent that calls are made where the argument and parameter have the same name, which leads to some duplication in the call:

    func(a=a, b=b, c=c, d=d)

For parameters with short names, such as these, the duplication is probably not really significant, but longer parameter names change that picture:

    func2(visibility=visibility, frobnification_level=frobnification_level)

In those cases, the duplication just adds a lot extra noise, so Joshua Bambrick suggested adding some syntactic sugar to avoid the problem; his goal is to promote the use of keyword arguments, which he believes are underused in part because of this visual noise.

His original suggestion was as follows:

    # instead of this:
    func2(visibility=visibility, frobnification_level=frobnification_level)

    # this could be used:
    func2(=visibility, =frobnification_level)

He had a long list of benefits, relating several of them to entries in PEP 20 ("The Zen of Python"); the overall idea is to increase the readability while reducing verbosity. The change would be backward compatible, because the new construct is a syntax error in today's Python.

Nir Schulman thought that it made more sense to put the "=" at the end of the parameter name; it may be easier to implement that way and it is analogous to the f-string f'{var=}' construct.

    func2(visibility=, frobnification_level=)

Guido van Rossum agreed with that second syntax and was willing to be the core-developer sponsor of a PEP if someone wanted to write one. Bambrick and several others quickly volunteered to work on it.

There were several commenters who were in favor of the idea and the "postfix" version, with the = after the parameter name, proved to be more popular, so it seems likely to be the syntax proposed in the PEP. But "Miraculixx" strongly disagreed; it will confuse beginners, they said, who are already somewhat confused by keyword arguments. They had their own list of quarrels with the idea (with nods to PEP 20 as well), many of which come down to personal preference (as, of course, do the benefits Bambrick listed). But Miraculixx also pointed out that it could lead to a somewhat subtle and possibly hard-to-find error: "renaming the variable in the calling context will break the code and it is not obvious to fix".

Paul Moore agreed with those arguments, noting that he would not use the feature himself, nor allow it in projects he maintains. He said that he can live with it if the feature gets added, but: "Python does seem to be gaining features I'm preferring not to use much more than features I'm enthusiastic about, these days :("

Numbers

Chris Angelico, who was one of those who volunteered to help with the PEP, thought that some of Miraculixx's complaints were not entirely reasonable. Angelico also did some research on the prevalence of "var=var" in the Python standard library; he found 3858 examples, which suggests to him that there is a real need for the feature. Likewise, Hugo van Kemenade found many instances of the pattern in other Python code bases. Angelico said that the short "x=x" examples do not really do justice to the idea; his search found 525 places where the identifiers were ten or more characters in length (310 if the unit tests are eliminated):

And I would absolutely argue that there's clarity to be gained here:

    ElementTree(element).write(stream, encoding,
                               xml_declaration=xml_declaration,
                               default_namespace=default_namespace,
                               method=method,
                               short_empty_elements=short_empty_elements)

# vs #

    ElementTree(element).write(stream, encoding,
                               xml_declaration=,
                               default_namespace=,
                               method=,
                               short_empty_elements=)

He further argued that brevity, in and of itself, is not really the goal; instead, the feature will help people spot problems:

When xml_declaration= is the norm, it's obvious that xml_declaration=html_declaration must be intentional and cannot possibly be a transcription error (okay, that particular example probably wouldn't happen, but you get the idea).

Inevitably, some bikeshedding over naming took place. Tamás Hadházy asked: "what this syntactic sugar should be called?" Ideas ranged from "implicit named arguments" through "abbreviated keyword arguments" and "elided keyword arguments" to "shorthand-keyword-arguments" (and others). Bambrick noted that other languages call it "punning", though the reasons for that may be a little obscure. There was no real consensus on a name, though Bambrick did use "punning" in an example pull request (PR) with a massive diff that modifies the standard library to use the new syntax.

The conversation soon wandered back to the feature itself. James Webber wondered if the perceived need for it was actually due to "bad ergonomics" of various sorts in function definitions:

Maybe I've converted too many things to be keyword-only, or I've ordered my arguments in a silly way (like, put uncommonly-specified arguments too early). Syntactic sugar covers up the mess a little but the code itself could be improved.

Moore agreed; "this feels like it's helping to make functions with lots of keyword arguments more tolerable, but maybe there's an underlying problem where a better API design would avoid the need for lots of keyword arguments in the first place?" Beyond that, though, the feature encourages using the same variable name inside and outside the function definition, which has some downsides: "the first is that it makes refactoring (a little) harder, and the second is that it discourages using more meaningful, less generic names for the variables in the caller".

But Angelico noted that the statistics tell a different story: "[...] this already happens in huge numbers of places. Clearly it's often the best choice even without this feature." Bambrick's changes for the standard library, and a similar example PR for pandas seemed to harden the opposition to the feature somewhat. Several responses in the thread indicated that the changes did not improve readability, at least for most commenters, though there were also a few new messages in support.

Some other possibilities for the syntax were mooted, though no real consensus emerged. Like many others, it is a proposal with some strong advocates and roughly as many naysayers. The PEP should help further the discussion, but the feature may well be too niche—and too disruptive—to go much beyond that. As alluded to by Moore and others, there seems to be some concerted effort toward proposing fairly small changes at the corners of the language these days. It remains to be seen whether the steering council (or its delegate) is amenable to that.

Comments (32 posted)

Better string handling for the kernel

The C programming language is replete with features that seemed like a good idea at the time (and perhaps even were good ideas then) that have not aged well. Most would likely agree that string handling, and the use of NUL-terminated strings, is one of those. Kernel developers have, for years, tried to improve the handling of strings in an attempt to slow the flow of bugs and vulnerabilities that result from mistakes in that area. Now there is an early discussion on the idea of moving away from NUL-terminated strings in much of the kernel.

The biggest problem with NUL-terminated strings is that they carry no information about the size of the buffer that contains them; that makes it easy to create buffer overflows. Over the years, a number of APIs have been created in an attempt to address this problem, adding functions like strncpy(), strlcpy(), and strscpy(), each of which is claimed to be better than its predecessors. None of them change the core concept of a NUL-terminated string, though, and none of them pleases everybody.

Over the years, the kernel has seen a long series of patches exchanging calls from one set of string functions for another. Sometimes those conversions have introduced bugs of their own, and maintainers have not always been happy with this work. Recently, in response to a patch converting strncpy() calls to strscpy() in the NVMe driver subsystem, Christoph Hellwig questioned the value of these changes:

We need to stop pretending that direct manipulation of nul-terminated strings is a good idea. I suspect the churn of replacing one helper with another, maybe slightly better, one probably introduces more bugs than it fixes.

Truly solving the problem, he said, requires using something better than NUL-terminated strings. He described the "seq_buf" API as "a good start" in this direction.

Seq_buf was introduced in 2014 for the 3.19 kernel release as an improved way to build strings in the tracing subsystem. It is organized around this structure:

    struct seq_buf {
	char			*buffer;
	size_t			size;
	size_t			len;
	loff_t			readpos;
    };

There is nothing revolutionary here; buffer points to the memory allocated by the string, and size is the size of that buffer. The length of the string stored in buffer is kept in len; the readpos field is used for reading through a string. The user must allocate buffer separately and attach it to a seq_buf with a call to:

    void seq_buf_init(struct seq_buf *s, char *buf, unsigned int size);

There is a whole set of functions for working with this structure, most of which have a fairly obvious purpose:

    void seq_buf_clear(struct seq_buf *s);
    int seq_buf_printf(struct seq_buf *s, const char *fmt, ...);
    int seq_buf_puts(struct seq_buf *s, const char *str);
    /* ... */

There are quite a few more; see include/linux/seq_buf.h for the full list.

Operations on a seq_buf are not allowed to overflow the given buffer; should an attempt be made to store too much data, a note will be made of the fact (len is set to a value greater than size) and future operations will fail. A call to seq_buf_has_overflowed() will return a boolean telling whether a seq_buf is in a good condition or not. This API allows for a long series of string operations, with only a single seq_buf_has_overflowed() check needed at the end to ensure that all is well; that simplifies error-handling code significantly.

There is no accessor function to obtain the string itself; users can just reach into the structure and use the buffer field directly. That string is maintained NUL-terminated, so it can be passed to functions expecting such strings — though they should not modify the buffer directly, of course.

The readpos field is only used within the tracing code. As a way of reducing the memory used by struct seq_buf in general, Matthew Wilcox recently posted a patch removing that field and pushing the concept of a read position into the code that uses it. That patch seems likely to be accepted, so readpos will probably not be a part of this structure going forward.

Kent Overstreet recently posted an alternative to seq_buf, called "printbuf", that takes a somewhat different approach. In the discussion of that patch set, he was advised to improve seq_buf instead, a suggestion that he has declined to pursue. So printbuf remains outside of the kernel, but it does appear in linux-next as part of the bcachefs series that (presumably) will be merged for 6.7. Whether printbuf will then be seen as an alternative to seq_buf is unclear, but the community is unlikely to want to maintain two similar string abstractions in the long term.

Will the kernel switch over to large-scale use of seq_buf (or printbuf) in the long term? It is hard to tell how far a conversion might go. Kees Cook said that, while seq_buf "shines" for complex string manipulation, it is more trouble than it is worth for the simple cases, which can be easily verified as correct in code using simpler APIs. Willy Tarreau, though, said that strings with explicit length counters are easier to work with in general, lead to simpler code, and can yield better performance as well. Meanwhile, Linus Torvalds, seemed mostly interested in getting rid of the remaining strlcpy() calls in the kernel and has not expressed an opinion on changing the kernel's handling of strings in general.

This conversation might encourage some developers to start using seq_buf in place of NUL-terminated C strings. Such a move is likely to start relatively slowly, though. If, over time, this approach starts to show benefits, there may eventually be a push to do conversions on a wider scale. But, no matter how it goes, the kernel seems likely to be managing a lot of NUL-terminated strings for a long time yet.

Comments (76 posted)

Deferred scheduling for user-space critical sections

User-space developers working with highly threaded applications would often like to be able to use spinlocks to protect shared data structures from concurrent access. There is a fundamental problem with user-space spinlocks, though: there is no way to prevent a thread from being preempted. Various ways of working around this problem have been explored, but this patch from Steven Rostedt questions the premise on which much of that work is based: what if it were possible to prevent preemption, for a short period at least?

Spinlocks are fast when there is no contention, and they can be acquired with no help from the kernel at all. The contended case is more problematic, though. A normal spinlock implementation would "spin" — repeatedly poll the state of the lock until it becomes available — in this case. But if the holder of the lock has been preempted and is not running, that spinning could go on indefinitely, wasting CPU time. Worse, the spinning thread might be the one that preempted the lock holder; in that case, spinning actively prevents the lock from being released. Either way, spinning on a lock held by a thread that is not running can ruin the performance of a system.

When using the kernel's futex mechanism, a thread waiting on a lock will call into the kernel and go to sleep until the lock is released; this works, but the cost of the system call can be prohibitive, even on Linux, where system calls are relatively fast. Work is underway on adaptive spinning, where a thread will only spin on a lock if the lock holder is currently running; that should make spinlocks work purely in user space much of the time. But a preempted lock holder will still force a call into the kernel and gum up the works in general. There would be value in letting lock holders run until they release their locks (as is done in most kernel configurations), avoiding the problem entirely, but letting unprivileged threads override the scheduler can create a whole range of problems of its own.

Rostedt thinks he has a way to allow a thread to request a bit more CPU time to complete a critical section, though, based on the lazy-preemption idea currently being discussed in the kernel community. Like the adaptive-spinning work, it is based on the restartable sequences feature, which is seemingly evolving into a mechanism for low-cost communication with the scheduler.

Rostedt's patch adds a new field, cr_flags, to the rseq structure shared between user space and the kernel. If a running thread sets the lowest-order bit (named RSEQ_CR_FLAG_IN_CRITICAL_SECTION), it indicates that the thread is currently running inside a critical section and would appreciate the opportunity to run uninterrupted for a little bit longer. The scheduler, before preempting a thread, will check that flag; if it is set, the scheduler will defer the preemption of that thread for a short period, much in the way that lazy preemption defers it in the kernel. That deferral is not guaranteed; if a realtime task needs to run, for example, it will get the CPU regardless of the setting of that bit. But in the absence of such tasks, the kernel will let a thread in a critical section run.

If, though, the kernel defers preemption in this way, it will set the RSEQ_CR_FLAG_KERNEL_REQUEST_SCHED bit in cr_flags. When the thread exits its critical section, it should check that flag and, if the flag is set, the thread should make a system call to let the kernel switch to the task it really wanted to be running. If the thread is still running when the next timer tick happens, it will be preempted regardless.

This feature might seem like a way for a malicious thread to get more than its share of the available CPU time. It could simply keep the critical-section bit set all the time and benefit from as much preemption deferral as it can get. The EEVDF scheduler that will be featured in the 6.6 kernel release, though, will note that a thread has gotten more than its share of CPU time and penalize it thereafter. So it should not be possible to game this mechanism to get more time overall and, with luck, there will not even be a need to add a way to detect threads that are attempting to abuse deferral in this way.

Deferred preemption, should it be merged, will not eliminate the need for adaptive spinning (or something like it); a lock-holding thread can still be preempted. But it should improve the performance of spinlock-using applications, perhaps significantly. When a lock-holding thread is preempted, any other thread needing that lock will be blocked as well, increasing the cost of that preemption significantly. By shifting preemption to times when it won't hurt other threads, this feature can avoid that penalty. Rostedt ran a simple benchmark that would appear to prove that point: "It was able to get into the critical section almost 1 million times more in those 5 seconds! That's a 23% improvement!". He suggested that deferred preemption might be useful for the implementation of spinlocks in guest kernels as well.

Whether this feature will be merged is an open question, though; scheduler maintainer Peter Zijlstra is not enthusiastic about it. He worries that no extension will be long enough, that deferred preemption might cause latency problems, that the mechanism still isn't reliable (applications can't count on preemption being deferred), and that the cost of using system calls for contended locks has been exaggerated. Rostedt answered that the interference with the scheduler's decisions should be minimal, and that real-world experience says that system calls are still too expensive to use in such situations. The extra time taken by a task when preemption is deferred, he said, is no worse than what might happen if it makes a long-running system call.

Whether this feature, or something evolved from it, will make it into the mainline is something that only time will tell. It has the potential to significantly improve the performance of certain classes of applications where performance matters a lot. More widespread testing would certainly be needed, though, to demonstrate that it cannot be used to ruin performance on other systems. The patch is relatively small, but the discussions around it may go on for some time yet.

Comments (6 posted)

Some 6.6 development statistics

The 6.6 kernel was released, right on schedule, on October 29. This development cycle saw the addition of 14,069 non-merge changesets from 1,978 developers — fairly typical numbers for recent releases. The time has come for LWN's traditional look at where the changes in this release came from, along with a look at the longer development "supercycle" that (probably) ends with 6.6.

Of the developers contributing to 6.6, 249 were new to the kernel community, again a fairly typical number. The most active 6.6 developers were:

Most active 6.6 developers

By changesets Krzysztof Kozlowski 311 2.2% Yangtao Li 296 2.1% Konrad Dybcio 188 1.3% Rob Herring 184 1.3% Thomas Zimmermann 158 1.1% Jeff Layton 149 1.1% Sean Christopherson 149 1.1% Jinjie Ruan 143 1.0% Yue Haibing 129 0.9% Mark Brown 118 0.8% Uwe Kleine-König 116 0.8% Christoph Hellwig 115 0.8% Ran Sun 114 0.8% Andy Shevchenko 108 0.8% Takashi Iwai 108 0.8% Matthew Wilcox 108 0.8% Dmitry Baryshkov 107 0.8% Kuninori Morimoto 106 0.8% Yang Yingliang 104 0.7% Jiri Slaby 99 0.7%

By changed lines Jiri Pirko 17444 3.0% Konrad Dybcio 16477 2.8% Ian Rogers 8991 1.5% Dmitry Baryshkov 8729 1.5% Charles Keepax 7834 1.3% Tomi Valkeinen 7647 1.3% Daniel Borkmann 7356 1.2% Neil Armstrong 7124 1.2% Danilo Krummrich 7122 1.2% Sui Jingfeng 6731 1.1% Darrick J. Wong 5819 1.0% Lorenzo Bianconi 5658 1.0% Tomeu Vizoso 5508 0.9% Fabio Estevam 5381 0.9% Takashi Iwai 5144 0.9% Jeff Layton 5064 0.9% Jorge Lopez 4821 0.8% Helge Deller 4742 0.8% Krzysztof Kozlowski 4705 0.8% Sricharan Ramabadhran 4506 0.8%

Krzysztof Kozlowski is, once again, at the top of the list of changeset contributors, having done a great deal of work in the devicetree subsystem. Yangtao Li mostly converted large numbers of drivers to use devm_platform_iomap_resource(). Konrad Dybcio worked mostly with devicetree files and Qualcomm drivers, Rob Herring worked extensively on devicetree-related code, and Thomas Zimmermann made many improvements to a range of graphics and frame-buffer drivers.

Developers often end up at the top of the "lines changed" column by virtue of a a small number of large patches. Jiri Pirko, instead, contributed 72 smaller patches refactoring and improving parts of the network-driver subsystem; Dybcio got there in a similar fashion. Ian Rogers made a number of changes (including removing perf BPF event support) to the perf events subsystem, Dmitry Baryshkov worked with Qualcomm drivers, and Charles Keepax added the cs42l43 audio driver.

The top testers and reviewers this time around were:

Test and review credits in 6.6
Tested-by Daniel Wheeler 103 6.5% Michael Kelley 60 3.8% Juergen Gross 60 3.8% Sohil Mehta 60 3.8% Nicolin Chen 39 2.5% Lad Prabhakar 38 2.4% John Allen 38 2.4% Kees Cook 37 2.3% Pengfei Xu 37 2.3% Yanting Jiang 36 2.3% Philipp Zabel 32 2.0% Niklas Söderlund 32 2.0% Aishwarya Kothari 32 2.0% Zhenzhong Duan 32 2.0%	Reviewed-by Simon Horman 322 3.7% Andy Shevchenko 227 2.6% Konrad Dybcio 162 1.9% Jan Kara 159 1.8% Krzysztof Kozlowski 151 1.8% Sam Ravnborg 116 1.3% Hans de Goede 112 1.3% Geert Uytterhoeven 108 1.3% Christoph Hellwig 97 1.1% David Sterba 90 1.0% Bard Liao 90 1.0% Kees Cook 85 1.0% Laurent Pinchart 85 1.0% Kevin Tian 84 1.0%

Daniel Wheeler, as usual, applies Tested-by tags to AMD GPU driver patches. Michael Kelley, Juergen Groess, and Sohil Mehta, instead, all tested the same set of x86 "APIC decrapification" patches from Thomas Gleixner. Overall, 1,067 patches (just under 8% of the total) merged for 6.6 contained Tested-by tags.

Simon Horman is the review champion for 6.6, having managed to review more than five networking patches for every day of this development cycle. There were 6,386 patches in 6.6 with Reviewed-by tags, or 45% of the total.

The most active employers this time around were:

Most active 6.6 employers

By changesets Linaro 1333 9.5% Intel 1221 8.7% Huawei Technologies 962 6.8% Red Hat 940 6.7% Google 937 6.7% (Unknown) 802 5.7% AMD 635 4.5% SUSE 590 4.2% (None) 505 3.6% NVIDIA 428 3.0% Oracle 400 2.8% Meta 338 2.4% vivo Mobile Communication Co 333 2.4% IBM 311 2.2% Renesas Electronics 257 1.8% Qualcomm 229 1.6% NXP Semiconductors 207 1.5% Pengutronix 176 1.3% Collabora 139 1.0% (Consultant) 132 0.9%

By lines changed Red Hat 56102 9.5% Linaro 48883 8.3% Intel 47457 8.0% NVIDIA 38849 6.6% Google 37066 6.3% AMD 26928 4.6% (Unknown) 23112 3.9% Oracle 18228 3.1% (None) 18014 3.0% IBM 17588 3.0% SUSE 16278 2.8% Cirrus Logic 15110 2.6% Meta 13967 2.4% Huawei Technologies 13436 2.3% Qualcomm 12773 2.2% Texas Instruments 12036 2.0% Loongson 10559 1.8% Collabora 10388 1.8% Ideas on Board 8083 1.4% MediaTek 8063 1.4%

Once again, there are few surprises here.

Closing the supercycle

In the absence of surprises, 6.6 will be the final release for 2023 and, as a result, the next long-term-support kernel release, with stable updates coming for the next two years. Since the LTS kernels are the ones that are actually used on most systems, the one-year LTS cycle represents a sort of kernel development supercycle. It thus makes some sense to look at contributions for that supercycle as a whole.

The last LTS kernel was 6.1, released on December 11, 2022. Since then, 72,425 non-merge changesets have found their way into the mainline, contributed by 4,598 developers, 1,359 of whom were first-time contributors. The most active developers were:

Most active developers, 6.2 through 6.6

By changesets Uwe Kleine-König 1903 2.6% Krzysztof Kozlowski 1774 2.4% Christoph Hellwig 739 1.0% Dmitry Baryshkov 728 1.0% Konrad Dybcio 624 0.9% Ian Rogers 612 0.8% Andy Shevchenko 602 0.8% Arnd Bergmann 563 0.8% Thomas Zimmermann 540 0.7% Hans de Goede 535 0.7% Rob Herring 510 0.7% Sean Christopherson 479 0.7% Ville Syrjälä 466 0.6% Mark Brown 400 0.6% Yangtao Li 398 0.5% Johan Hovold 383 0.5% Geert Uytterhoeven 340 0.5% Jakub Kicinski 335 0.5% Thomas Gleixner 325 0.4% Christophe JAILLET 315 0.4%

By changed lines Ian Rogers 354263 8.8% Arnd Bergmann 176229 4.4% Hawking Zhang 140929 3.5% Ping-Ke Shih 61180 1.5% Greg Kroah-Hartman 59531 1.5% Kalle Valo 54241 1.3% Konrad Dybcio 40815 1.0% Dmitry Baryshkov 38798 1.0% Krzysztof Kozlowski 37185 0.9% Jakub Kicinski 35614 0.9% Hans Verkuil 33750 0.8% Eduard Zingerman 28785 0.7% Steen Hegelund 26899 0.7% Hans de Goede 26281 0.7% Laurent Pinchart 24177 0.6% Wenjing Liu 23460 0.6% Ben Skeggs 23413 0.6% Zong-Zhe Yang 22776 0.6% Cai Huoqing 21108 0.5% Neil Armstrong 21069 0.5%

The two most active developers each managed to crank out just short of six patches per day — every day — in the 322 days that separated the two LTS releases; 19 developers contributed at least one patch per day during that time. Two of the biggest contributors of new lines of code, Ian Rogers and Hawking Zhang, added Intel perf event definitions and AMD GPU register definitions, respectively. Arnd Bergmann, instead, managed to delete over 170,000 lines of code during this period.

The employer numbers for this time period look like this:

Most active employers, 6.2 through 6.6

By changesets Intel 7488 10.3% Linaro 6882 9.5% Google 4990 6.9% Red Hat 4642 6.4% (Unknown) 4546 6.3% AMD 3709 5.1% (None) 3037 4.2% Huawei Technologies 2801 3.9% Pengutronix 2234 3.1% SUSE 2088 2.9% NVIDIA 2088 2.9% Meta 1865 2.6% Oracle 1718 2.4% IBM 1608 2.2% (Consultant) 1207 1.7% Qualcomm 1140 1.6% Renesas Electronics 1066 1.5% NXP Semiconductors 962 1.3% Collabora 746 1.0% Arm 680 0.9%

By lines changed Google 482473 12.0% Linaro 435631 10.8% AMD 315689 7.8% Intel 309591 7.7% Red Hat 235604 5.8% (Unknown) 200825 5.0% Qualcomm 147468 3.7% NVIDIA 139600 3.5% Meta 111214 2.8% Realtek 106662 2.6% (None) 100191 2.5% SUSE 83300 2.1% IBM 72711 1.8% Linux Foundation 68750 1.7% Microchip Technology Inc. 66363 1.6% MediaTek 65067 1.6% Oracle 60791 1.5% Collabora 55622 1.4% (Consultant) 52382 1.3% Renesas Electronics 43984 1.1%

One other statistic that can be worth a look is the application of Signed-off-by tags by developers other than the author of any given patch. Those tags are added whenever a maintainer applies a patch to a repository, bringing it into the Git-based flow. Looking at non-author signoffs, thus, can provide a picture of who the busiest maintainers are. For the extended 6.6 cycle, the results are:

Top non-author signoffs, 6.2 to 6.6

Individuals Greg Kroah-Hartman 3124 4.5% Mark Brown 3080 4.5% Alex Deucher 3007 4.4% Andrew Morton 2769 4.0% Jakub Kicinski 2681 3.9% Bjorn Andersson 2662 3.9% David S. Miller 2467 3.6% Arnaldo Carvalho de Melo 1206 1.8% Mauro Carvalho Chehab 1197 1.7% Jens Axboe 1098 1.6% Martin K. Petersen 1019 1.5% Kalle Valo 995 1.4% Hans Verkuil 983 1.4% Vinod Koul 945 1.4% Alexei Starovoitov 929 1.4% David Sterba 887 1.3% Shawn Guo 706 1.0% Paolo Abeni 691 1.0% Jonathan Cameron 663 1.0% Lee Jones 655 1.0%

Companies Linaro 8043 11.7% Red Hat 7698 11.2% Google 7591 11.1% Intel 7403 10.8% Meta 5675 8.3% Qualcomm 4219 6.1% AMD 3782 5.5% Linux Foundation 3487 5.1% SUSE 2684 3.9% NVIDIA 1839 2.7% IBM 1455 2.1% Oracle 1308 1.9% (Unknown) 1225 1.8% (None) 1213 1.8% Huawei Technologies 1053 1.5% Cisco 984 1.4% (Consultant) 946 1.4% Microsoft 879 1.3% Bootlin 552 0.8% Texas Instruments 502 0.7%

Greg Kroah-Hartman fell just short of applying ten patches every day, including weekends and holidays, during this period — and that does not count all of the patches that he herds into the stable kernels. On the employer side, it's evident that there are still relatively few companies that employ maintainers; over 50% of the changes going into the kernel pass through the hands of maintainers working for just five companies.

The kernel's development process continues at full speed, producing a new major release every nine or ten weeks. The 6.7 release is more likely to be ten weeks than nine as a result of the upcoming holiday season. It is also likely to be a big release; there are, as of this writing, nearly 16,000 changesets waiting in linux-next. As always, keep an eye on LWN to stay on top of what is happening as this next cycle unfolds.

Comments (none posted)

Rust code review and netdev

A fast-moving patch set—seemingly the norm for Linux networking development—seeks to add some Rust abstractions for physical layer (PHY) drivers. Lots of review has been done, and the patch set has been reworked frequently in response to those comments. Unfortunately, the Rust-for-Linux developers are having trouble keeping up with that pace. There is, it would appear, something of a disconnect between the two communities' development practices.

On October 26, Tomonori Fujita posted version 7 of his patches containing the infrastructure for creating some PHY drivers using Rust; it also includes a driver for the Asix AX88772A PHY. The first version was posted on October 2 and it was preceded by three RFCs starting on September 13. In response to the cover letter for version 7, Rust-for-Linux developer Miguel Ojeda suggested that Fujita slow the pace some:

This patch series has had 8 versions in a month. It would be better to wait more between revisions for this kind of patch series, especially when there is discussion still going on in the previous ones and it is a new "type" of code.

I understand you are doing it so that people can see the latest version (and thus focus on that), and that is helpful, but sending versions very quickly when the discussions are ongoing splits the discussions into several versions. That makes it more confusing for reviewers, and essentially discourages people from being able to follow everything.

But Andrew Lunn, who has been doing a lot of review of the patches, pointed out that the pace is what is expected for the Linux networking subsystem: "[...] netdev moves fast, review comments are expected within about 3 days". He said that new versions of a patch set should not be posted for at least 24 hours, but the fast pace is meant to drive a resolution sooner; "[...] posting a new version is a way to kick reviewers into action". But Rust-for-Linux developer Boqun Feng wondered if posting updated patch sets so frequently really meets that goal: "it's sometimes [frustrating] to see new version post but old comments were not resolved, it rather discourages reviewers".

Lunn also noted that networking patches do not require reviews in order to get merged; "If there is no feedback within three days, and it passes the CI [continuous-integration] tests, it likely will be merged." But Ojeda said that CI tests are not sufficient to determine if the abstractions are "well-designed or sound, which is the key property Rust abstractions need" (see this post for a description of "sound" in Rust terms); he hoped that there were humans in the loop. Lunn replied that humans ultimately decide whether to merge the code, but that API problems are just bugs like any other—they can be fixed later if any are found.

In another part of the thread, Ojeda described the differences he sees between the processes for the netdev community and that of the (nascent) Rust-for-Linux effort. There is a need for the project to do careful review of "a whole new subsystem API" in a new language, he said. Another difficulty is that the Rust-for-Linux project simply does not have enough reviewers and/or review bandwidth to keep up with the netdev pace. "So, if you appreciate/want/need our feedback, you will need to be a bit more patient."

Meanwhile, though, he also quoted parts of the netdev documentation that indicate posting a new revision is not the recommended path to speed things along. In particular: "Do not post a new version of the code if the discussion about the previous version is still ongoing, unless directly instructed by a reviewer." In fact, that is the norm in the rest of the kernel community: posting a new patch set before the discussion has died down is generally unwelcome.

Networking maintainer Jakub Kicinski acknowledged the Rust-for-Linux project's needs, but pointed out that the netdev process is meant to make it possible to handle an enormous patch volume. "Longer review cycles would make keeping track of patches and discussions unmanageable." He wondered if the Rust-for-Linux project would be less involved in patch review after the initial stages. Ojeda agreed that was the goal, but that the initial set of abstractions will require more review time:

In addition, for Rust, we are trying to get the very first abstractions that get into mainline as reasonably well-designed as we can (and ideally "sound"), so that they can serve as an example. This takes time, and typically several iterations.

There is also a need to spend some time on "getting people on the same page around what is expected from Rust code and abstractions", he said. There is more to it than just the design and logic in the code, as formatting is part of what needs to be hammered out. A "trivial example" of that is the maximum line length that Lunn had pointed out as a problem in his review. Ojeda said that the Rust-for-Linux project would like to have consistent formatting for its code throughout the kernel, hopefully maintained in an automated fashion, so those differences need to be ironed out kernel-wide if possible. The plan is to provide a solid foundation so that the networking developers "can actually handle any patches swiftly without having to wait on us"—but it is going to take some time to get there.

Lunn cautioned that it may be difficult to achieve the consistency the project is hoping for—at least for line lengths. The netdev community prefers 80-character lines, while other subsystems use 100-character lines and may not like the shorter lines. In the end, formatting is not really a technical problem, but a social issue, Lunn said:

In order to keep the netdev people happy, you are going to limit it to 80. But i would not be too surprised if another subsystem says the code would be more readable with 100, like the C code in our subsystem. We want Rust to be 100 as well.

Linux can be very fragmented like this across subsystems. Its just the way it is, and you might just have to fit in.

Ojeda seems adamant that the Rust code will be consistently formatted throughout the kernel, which is a departure from the (lack of) consistency of the existing C code. We will have to see how that plays out over time. The discussion highlights some of the problems that will need to be worked out when two disparate development communities "collide". The PHY abstractions and the driver using them would be the first Rust kernel feature that is visible to both driver writers and regular users, so it is no surprise that the developers want to take the time to get it right.

The Linux development pace is far faster than most other development projects, which may simply be too fast for the kernel Rust project—at least at this point. On the other hand, the Rust APIs are not something that have to be set in stone, as Lunn noted; they are internal to the kernel and, thus, can be changed as with other kernel APIs. One senses that the two projects will find a balance that works for both, perhaps assisted by conversations at the upcoming Linux Plumbers Conference in mid-November.

Comments (31 posted)

Help wanted at LWN

LWN.net is looking to hire a full-time writer/editor to help us keep the news flowing and to expand our content in areas of interest to our readers. We are certain that the person we need is out there somewhere, and are counting on help from LWN readers to find them. Read on for details on who we are looking for and how we see them fitting in here.

Please note: applications for this position are closed, at least for now. We are always looking for freelance writers, though; if that appeals to you, please have a look at the Writing for LWN page.

LWN has always set an ambitious goal for itself: making what is happening in the Linux and free-software-development communities clear and understandable to those who are a part of it in any way — or who would like to be. It is a far bigger job than even a larger LWN could do, but we do the best that we can. To do better, we need more people with the energy and desire to pick up part of the load. Fortunately, we are in a position where we can bring in such a person full time.

The ideal LWN writer is immersed in the free-software world and has a wide view of what is happening within it. They want to be learning constantly and are interested in going out into the development community. We are looking for somebody who is enthusiastic about communicating what they learn to a wide audience, part of which knows more about the material at hand regardless of the specific subject matter. Preferably, they would like to broaden our coverage in an adjacent area: Rust, Android, toolchains, distributions, security, or any of a number of other possibilities. Ideally, they would want to go beyond just writing and take an active role in directing LWN's future.

The full job description appears below.

LWN writer/editor

LWN.net is seeking a full-time technical journalist to provide high-quality coverage of the Linux and free-software communities for our readers. This is an opportunity to be a part of a community that has changed the world and is far from finished. LWN has been covering this community from within since 1998.

Responsibilities will include finding and researching topics, writing articles on a regular schedule, reviewing articles written by others, interacting with readers, and traveling to and reporting from community events. Additionally, we all take part in the tasks of running the business and making important decisions about where we are trying to go.

Requirements include:

• A university degree in technical writing, engineering, or the sciences, or equivalent experience.
• Excellent English writing and editing skills.
• The willingness and ability to work remotely full-time.
• An understanding of free software and the communities that create it.
• A willingness to take on a wide range of challenges in a small-company environment.

We would also like to see:

• A demonstrated history of writing for a highly technical audience.
• Software development experience, especially in the form of contribution to one or more free-software projects.
• Experience with web technologies and web-site design.
• Python development experience.
• An interest in traveling to attend conferences and other community events.

LWN is located in Colorado, in the US. For candidates within the US, we are offering a salary range of $70,000 to $140,000 per year, health insurance, and a 5% 401(k) match. We are happy to consider applications from outside of the US as well; in such a case, salary and benefits will be dependent on what we are able to arrange in the specific location.

To apply for this position, please contact us at editorjob@lwn.net and tell us about the topic areas you would be most interested in covering.

Finding this person is crucial to the long-term future of LWN; we have been understaffed for some time, and that is making itself felt. So we are asking all LWN readers to think about whose words they would like to read on these pages. If you know somebody who might make a good candidate, please direct their attention this way and encourage them to apply.

Comments (none posted)

Removing syscall() from OpenBSD

For a view into the OpenBSD approach to security, see this message from Theo de Raadt, where he describes a plan to remove the syscall() system call (which allows the invocation of any available system call by providing its number) from the kernel. The purpose, of course, is to make it harder for an attacker to invoke an arbitrary system call, even if they are able to run some code on the target system.

I hope I am forcing attack coders into using increasingly more complicated methods. Same time, it means fewer methods are available. Other methods make exploitation more fragile. This is pushing success rates into "low-percent statistical" success. If we teach more software stacks to "fail hard, don't try to recover", that is an improvement in security.

Full Story (comments: 33)

Security quote of the week

Amazon can do this because the Alexa's operating system sits behind a cryptographic lock, and any tool that bypasses that lock is a felony under Section 1201 of the DMCA, punishable by a 5-year prison sentence and a $500,000 fine. That means that it's literally a crime to provide a rival OS that lets users retain functionality that Amazon no longer supports.

This is the proverbial gun on the mantelpiece, a moral hazard and invitation to mischief that tempts Amazon executives to run a bait-and-switch con where they sell you a gadget with five features and then remotely kill-switch two of them. This is prime directive of the Darth Vader MBA: "I am altering the deal. Pray I don't alter it any further."

— Cory Doctorow on Amazon killing Alexa integration with IFTTT

Comments (29 posted)

Kernel release status

The 6.6 kernel was released on October 29; Linus commented: "So this last week has been pretty calm, and I have absolutely no excuses to delay the v6.6 release any more, so here it is."

Headline features in 6.6 include the earliest eligible virtual deadline first (EEVDF) CPU scheduler, a number of enhancements (quota support, user extended attributes, direct I/O) to the tmpfs filesystem, the fchmodat2() system call, initial support for building a kernel without buffer-head support, the kmalloc() randomness patches, user-space shadow stacks for Intel CPUs, and quite a bit more. See the LWN merge window summaries (part 1, part 2) and the KernelNewbies 6.6 page for more information.

Stable updates: none have been released in the last week. The 6.5.10 and 6.1.61 updates are in the review process; they are due on or after November 2.

Comments (1 posted)

Garrett: Why ACPI?

Matthew Garrett explains why ACPI exists and why it is not as bad a thing as some think.

There's an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we've seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?

Comments (50 posted)

A recent talk on kernel maintainership

LWN editor Jonathan Corbet was asked to give a brief talk about kernel maintainership at the recently concluded Linux Foundation Member Summit. That talk was recorded and has now been made available on YouTube. There is little in it that will be news to regular LWN readers, but it may be instructive to folks who are less well versed in how kernel development works.

Comments (5 posted)

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

The New Stack covers a conference talk by Bjarne Stroustrup on turning C++ into a safer language.

Stroustrup has arrived at his solution: profiles. (That is, a set of rules which, when followed, achieve specific safety guarantees.) They’d be defined by the ISO C++ standard, addressing common safety issues like pointers and array ranges. In response to a later question from the audience about the difficulty of adding new tooling, Stroustrup pointed out that the C++ compiler itself is now a pretty sophisticated static analyzer, and could also be tasked with meeting the profile's requirements.

Comments (328 posted)

Incus 0.2 released

Version 0.2 of Incus, an LXD fork, has been released. "This version incorporates most changes that went into LXD 5.19 as well as introduce a few additional features and improvements." Changes include NVME storage support, support for migrating clustered environments from LXD, and more.

Comments (4 posted)

CFP Deadlines: November 2, 2023 to January 1, 2024

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

Deadline	Event Dates	Event	Location
November 30	February 27	Open Source Camp on Kubernetes	Nuremberg, Germany
December 16	April 12 April 13	Texas Linux Fest	Austin, Texas, US

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

Events: November 2, 2023 to January 1, 2024

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

Date(s)	Event	Location
October 30 November 3	Netdev 0x17	Vancouver, Canada
November 3 November 4	Seattle GNU/Linux Conference 2023	Seattle, US
November 3 November 5	Ubuntu Summit	Riga, Latvia
November 4 November 5	OpenFest 2023	Sofia, Bulgaria
November 7 November 9	Open Source Monitoring Conference	Berlin, Germany
November 9 November 10	Fourth LibreOffice Latin America Congress	Mexico City, Mexico
November 11	Clang-built Linux Meetup	Richmond, VA, US
November 13 November 15	Linux Plumbers Conference	Richmond, VA, US
November 25 November 26	MiniDebConf Cambridge	Cambridge, UK
November 27 November 29	Deutsche Open Stack Tage	Berlin, Germany
November 28	NLUUG Fall Conference	Utrecht, The Netherlands
November 28 November 30	Yocto Project Summit 2023.11	Online
December 1 December 3	GNOME.Asia 2023	Kathmandu, Nepal
December 2 December 3	EmacsConf 2023	Online
December 5 December 6	Open Source Summit Japan	Tokyo, Japan
December 12 December 15	PostgreSQL Conference Europe	Prague, Czechia

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

Alert summary October 26, 2023 to November 1, 2023

Dist.	ID	Release	Package	Date
Debian	DSA-5536-1	stable	chromium	2023-10-26
Debian	DLA-3640-1	LTS	distro-info	2023-10-30
Debian	DLA-3639-1	LTS	distro-info-data	2023-10-30
Debian	DLA-3632-1	LTS	firefox-esr	2023-10-27
Debian	DSA-5535-1	stable	firefox-esr	2023-10-25
Debian	DLA-3633-1	LTS	gst-plugins-bad1.0	2023-10-28
Debian	DLA-3638-1	LTS	h2o	2023-10-31
Debian	DLA-3641-1	LTS	jetty9	2023-10-30
Debian	DSA-5540-1	stable	jetty9	2023-10-30
Debian	DLA-3635-1	LTS	node-browserify-sign	2023-10-29
Debian	DSA-5539-1	stable	node-browserify-sign	2023-10-30
Debian	DLA-3634-1	LTS	nss	2023-10-28
Debian	DSA-5543-1	stable	open-vm-tools	2023-10-31
Debian	DLA-3636-1	LTS	openjdk-11	2023-10-29
Debian	DSA-5537-1	stable	openjdk-11	2023-10-27
Debian	DLA-3643-1	LTS	pmix	2023-10-31
Debian	DLA-3642-1	LTS	request-tracker4	2023-10-31
Debian	DSA-5542-1	stable	request-tracker4	2023-10-30
Debian	DSA-5541-1	stable	request-tracker5	2023-10-30
Debian	DLA-3637-1	LTS	thunderbird	2023-10-29
Debian	DSA-5538-1	stable	thunderbird	2023-10-28
Debian	DLA-3631-1	LTS	xorg-server	2023-10-25
Debian	DSA-5544-1	stable	zookeeper	2023-10-31
Fedora	FEDORA-2023-a9062a0411	F38	chromium	2023-10-29
Fedora	FEDORA-2023-fef2b8da32	F37	curl	2023-10-28
Fedora	FEDORA-2023-4e191bea36	F37	firefox	2023-10-27
Fedora	FEDORA-2023-7cdf31bb36	F38	firefox	2023-10-26
Fedora	FEDORA-2023-ab43e2ce21	F39	golang-github-altree-bigfloat	2023-10-31
Fedora	FEDORA-2023-ab43e2ce21	F39	golang-github-seancfoley-bintree	2023-10-31
Fedora	FEDORA-2023-ab43e2ce21	F39	golang-github-seancfoley-ipaddress	2023-10-31
Fedora	FEDORA-2023-ab43e2ce21	F39	kitty	2023-10-31
Fedora	FEDORA-2023-e0ab860391	F37	mbedtls	2023-10-26
Fedora	FEDORA-2023-b2c50535cb	F37	nghttp2	2023-10-28
Fedora	FEDORA-2023-e9c04d81c1	F37	nodejs18	2023-10-26
Fedora	FEDORA-2023-f66fc0f62a	F37	nodejs20	2023-10-26
Fedora	FEDORA-2023-4d2fd884ea	F38	nodejs20	2023-10-26
Fedora	FEDORA-2023-8a9087f089	F37	redis	2023-10-27
Fedora	FEDORA-2023-77ed1e26a4	F38	redis	2023-10-27
Fedora	FEDORA-2023-fff0c857d6	F37	samba	2023-10-27
Fedora	FEDORA-2023-1f851fa869	F37	slurm	2023-10-31
Fedora	FEDORA-2023-234df8a1d4	F38	slurm	2023-10-31
Fedora	FEDORA-2023-126cffa741	F38	thunderbird	2023-10-31
Fedora	FEDORA-2023-881672fdab	F37	xen	2023-10-27
Fedora	FEDORA-2023-a4c606585e	F38	xen	2023-10-26
Fedora	FEDORA-2023-7a94186139	F38	xorg-x11-server-Xwayland	2023-10-29
Gentoo	202310-21		ConnMan	2023-10-31
Gentoo	202310-19		Dovecot	2023-10-30
Gentoo	202311-01		GitPython	2023-11-01
Gentoo	202310-18		Rack	2023-10-30
Gentoo	202310-22		Salt	2023-10-31
Gentoo	202310-15		USBView	2023-10-26
Gentoo	202310-17		UnZip	2023-10-30
Gentoo	202310-14		libinput	2023-10-26
Gentoo	202310-23		libxslt	2023-10-31
Gentoo	202310-20		rxvt-unicode	2023-10-30
Gentoo	202310-16		unifi	2023-10-26
Mageia	MGASA-2023-0304	8, 9	apache	2023-10-27
Mageia	MGASA-2023-0303	9	bind	2023-10-27
Mageia	MGASA-2023-0306	9	chromium-browser-stable	2023-10-31
Mageia	MGASA-2023-0302	8	python-nltk	2023-10-25
Mageia	MGASA-2023-0305	8, 9	vim	2023-10-27
Oracle	ELSA-2023-6162	OL7	firefox	2023-10-31
Oracle	ELSA-2023-6162	OL7	firefox	2023-10-31
Oracle	ELSA-2023-6187	OL8	firefox	2023-10-31
Oracle	ELSA-2023-5742	OL8	java-11-openjdk	2023-10-31
Oracle	ELSA-2023-5744	OL9	java-11-openjdk	2023-10-31
Oracle	ELSA-2023-5751	OL8	java-17-openjdk	2023-10-31
Oracle	ELSA-2023-5753	OL9	java-17-openjdk	2023-10-31
Oracle	ELSA-2023-6167	OL9	libguestfs-winsupport	2023-10-31
Oracle	ELSA-2023-5068	OL9	linux-firmware	2023-10-26
Oracle	ELSA-2023-6120	OL9	nginx:1.22	2023-10-31
Oracle	ELSA-2023-5998	OL8	python39:3.9, python39-devel:3.9	2023-10-26
Oracle	ELSA-2023-6193	OL7	thunderbird	2023-10-31
Oracle	ELSA-2023-6193	OL7	thunderbird	2023-10-31
Oracle	ELSA-2023-6194	OL8	thunderbird	2023-10-31
Oracle	ELSA-2023-6191	OL9	thunderbird	2023-10-31
Red Hat	RHSA-2023:6162-01	EL7	firefox	2023-10-30
Red Hat	RHSA-2023:6187-01	EL8	firefox	2023-10-30
Red Hat	RHSA-2023:6189-01	EL8.1	firefox	2023-10-30
Red Hat	RHSA-2023:6185-01	EL8.2	firefox	2023-10-30
Red Hat	RHSA-2023:6190-01	EL8.4	firefox	2023-10-30
Red Hat	RHSA-2023:6186-01	EL8.6	firefox	2023-10-30
Red Hat	RHSA-2023:6188-01	EL9	firefox	2023-10-30
Red Hat	RHSA-2023:6199-01	EL9.0	firefox	2023-10-30
Red Hat	RHSA-2023:6167-01	EL9	libguestfs-winsupport	2023-10-30
Red Hat	RHSA-2023:6168-01	EL9.0	libguestfs-winsupport	2023-10-30
Red Hat	RHSA-2023:6120-01	EL9	nginx:1.22	2023-10-25
Red Hat	RHSA-2023:6209-01	EL9.0	samba	2023-10-31
Red Hat	RHSA-2023:6193-01	EL7	thunderbird	2023-10-30
Red Hat	RHSA-2023:6194-01	EL8	thunderbird	2023-10-30
Red Hat	RHSA-2023:6198-01	EL8.1	thunderbird	2023-10-30
Red Hat	RHSA-2023:6197-01	EL8.2	thunderbird	2023-10-30
Red Hat	RHSA-2023:6196-01	EL8.4	thunderbird	2023-10-30
Red Hat	RHSA-2023:6195-01	EL8.6	thunderbird	2023-10-30
Red Hat	RHSA-2023:6191-01	EL9	thunderbird	2023-10-30
Red Hat	RHSA-2023:6192-01	EL9.0	thunderbird	2023-10-30
Red Hat	RHSA-2023:6022-01	EL8.2	varnish:6	2023-10-27
Red Hat	RHSA-2023:6021-01	EL8.4	varnish:6	2023-10-27
Slackware	SSA:2023-299-01		mozilla	2023-10-26
Slackware	SSA:2023-299-02		xorg	2023-10-26
SUSE	openSUSE-SU-2023:0325-1	osB15	chromium	2023-10-26
SUSE	SUSE-SU-2023:4297-1	SLE12	clamav	2023-10-31
SUSE	SUSE-SU-2023:4309-1	MP4.3 SLE15 SES7.1	container-suseconnect	2023-10-31
SUSE	SUSE-SU-2023:4214-1	MP4.3 SLE15 SES7.1 oS15.4 oS15.5	firefox	2023-10-26
SUSE	SUSE-SU-2023:4212-1	SLE12	firefox	2023-10-26
SUSE	SUSE-SU-2023:4213-1	SLE15	firefox	2023-10-26
SUSE	SUSE-SU-2023:4287-1	SLE12 SLE15	gcc13	2023-10-31
SUSE	SUSE-SU-2023:4271-1	SLE15 SLE-m5.5 oS15.5	gstreamer-plugins-bad	2023-10-30
SUSE	SUSE-SU-2023:3563-3	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 osM5.2 osM5.3 osM5.4	icu73_2	2023-10-30
SUSE	SUSE-SU-2023:4198-1	MP4.2 MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.4 oS15.5	java-11-openjdk	2023-10-26
SUSE	SUSE-SU-2023:4289-1	MP4.3 SLE15 oS15.4 oS15.5	java-17-openjdk	2023-10-31
SUSE	SUSE-SU-2023:4210-1	MP4.3 SLE15 SES7.1 oS15.4 oS15.5	jetty-minimal	2023-10-26
SUSE	SUSE-SU-2023:4222-1	oS15.3 oS15.4 oS15.5	libnbd	2023-10-27
SUSE	SUSE-SU-2023:4330-1	MP4.2 MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.4 oS15.5	libsndfile	2023-11-01
SUSE	SUSE-SU-2023:4331-1	SLE12	libsndfile	2023-11-01
SUSE	SUSE-SU-2023:4200-1	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.4 oS15.5 osM5.3 osM5.4	nghttp2	2023-10-26
SUSE	SUSE-SU-2023:4199-1	SLE12	nghttp2	2023-10-26
SUSE	SUSE-SU-2023:4295-1	SLE15 oS15.4	nodejs10	2023-10-31
SUSE	SUSE-SU-2023:4259-1	SLE12	nodejs12	2023-10-30
SUSE	SUSE-SU-2023:4207-1	SLE15 SES7.1 oS15.3	nodejs18	2023-10-26
SUSE	SUSE-SU-2023:4227-1	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.3 oS15.4 oS15.5 osM5.3 osM5.4	open-vm-tools	2023-10-27
SUSE	SUSE-SU-2023:4228-1	SLE12	open-vm-tools	2023-10-27
SUSE	SUSE-SU-2023:4229-1	SLE15	open-vm-tools	2023-10-27
SUSE	SUSE-SU-2023:4230-1	SLE15	open-vm-tools	2023-10-27
SUSE	openSUSE-SU-2023:0337-1	oS15.4	opera	2023-10-29
SUSE	openSUSE-SU-2023:0338-1	oS15.5	opera	2023-10-29
SUSE	SUSE-SU-2023:4291-1	SLE15 SLE-m5.5 oS15.5	poppler	2023-10-31
SUSE	SUSE-SU-2023:4270-1	oS15.4	poppler	2023-10-30
SUSE	SUSE-SU-2023:4232-1	OS8 SLE12	python-Django	2023-10-27
SUSE	SUSE-SU-2023:4220-1	MP4.2 MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5	python	2023-10-26
SUSE	SUSE-SU-2023:4288-1	MP4.3 SLE15 oS15.4 oS15.5	python-Werkzeug	2023-10-31
SUSE	openSUSE-SU-2023:0334-1	osB15	python-bugzilla	2023-10-27
SUSE	SUSE-SU-2023:4290-1	MP4.3 SLE15 oS15.4 oS15.5	redis	2023-10-31
SUSE	SUSE-SU-2023:4329-1	SLE15 oS15.4 oS15.5	slurm	2023-11-01
SUSE	openSUSE-SU-2023:0328-1	osB15	sox	2023-10-26
SUSE	openSUSE-SU-2023:0329-1	osB15	sox	2023-10-26
SUSE	SUSE-SU-2023:4302-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5	thunderbird	2023-10-31
SUSE	SUSE-SU-2023:4251-1	MP4.3 SLE15 SES7.1 oS15.4 oS15.5	vorbis-tools	2023-10-30
SUSE	SUSE-SU-2023:4218-1	SLE12	vorbis-tools	2023-10-26
SUSE	SUSE-SU-2023:4294-1	MP4.3 SLE15 oS15.4 oS15.5	webkit2gtk3	2023-10-31
SUSE	SUSE-SU-2023:4209-1	SLE12	webkit2gtk3	2023-10-26
SUSE	SUSE-SU-2023:4211-1	SLE15	webkit2gtk3	2023-10-26
SUSE	SUSE-SU-2023:4292-1	MP4.3 SLE15 oS15.4	xorg-x11-server	2023-10-31
SUSE	SUSE-SU-2023:4269-1	SLE12	xorg-x11-server	2023-10-30
SUSE	SUSE-SU-2023:4272-1	SLE15 oS15.5	xorg-x11-server	2023-10-30
SUSE	SUSE-SU-2023:4293-1	SLE15 oS15.4	xwayland	2023-10-31
SUSE	SUSE-SU-2023:4306-1	SLE15 oS15.5	xwayland	2023-10-31
SUSE	SUSE-SU-2023:4224-1	MP4.2 SLE15 SES7.1	zchunk	2023-10-27
SUSE	SUSE-SU-2023:4225-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5 osM5.3 osM5.4	zchunk	2023-10-27
SUSE	SUSE-SU-2023:4217-1	MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 oS15.4 osM5.3 osM5.4	zlib	2023-10-26
SUSE	SUSE-SU-2023:4216-1	SLE12	zlib	2023-10-26
SUSE	SUSE-SU-2023:4215-1	SLE15 SLE-m5.5 oS15.5	zlib	2023-10-26
Ubuntu	USN-6455-1	14.04 16.04 18.04 20.04 22.04 23.04 23.10	exim4	2023-10-30
Ubuntu	USN-6456-1	20.04	firefox	2023-10-30
Ubuntu	USN-6460-1	14.04	kernel	2023-10-30
Ubuntu	USN-6467-1	14.04 16.04 18.04	krb5	2023-11-01
Ubuntu	USN-6465-1	20.04 22.04	linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gcp-5.15, linux-gkeop, linux-gkeop-5.15, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15	2023-10-31
Ubuntu	USN-6462-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp	2023-10-31
Ubuntu	USN-6464-1	22.04 23.04	linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2, linux-azure-fde-6.2, linux-gcp, linux-gcp-6.2, linux-hwe-6.2, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-6.2, linux-oracle, linux-raspi, linux-starfive	2023-10-31
Ubuntu	USN-6454-1	23.10	linux, linux-lowlatency	2023-10-26
Ubuntu	USN-6454-2	23.10	linux-aws, linux-azure, linux-gcp, linux-oracle, linux-raspi	2023-10-30
Ubuntu	USN-6441-3	18.04 20.04	linux-iot, linux-raspi, linux-raspi-5.4	2023-10-30
Ubuntu	USN-6454-3	23.10	linux-laptop	2023-10-31
Ubuntu	USN-6466-1	22.04	linux-nvidia-6.2	2023-10-31
Ubuntu	USN-6461-1	22.04	linux-oem-6.1	2023-10-31
Ubuntu	USN-6446-3	20.04	linux-oracle-5.15	2023-10-26
Ubuntu	USN-6465-2	22.04	linux-raspi	2023-11-01
Ubuntu	USN-6459-1	20.04 22.04 23.04 23.10	mysql-8.0	2023-10-30
Ubuntu	USN-6457-1	22.04	nodejs	2023-10-30
Ubuntu	USN-6463-1	20.04 22.04 23.04 23.10	open-vm-tools	2023-10-31
Ubuntu	USN-6458-1	20.04 22.04	slurm-llnl, slurm-wlm	2023-10-30
Ubuntu	USN-6452-1	14.04 16.04 18.04 20.04 22.04 23.04 23.10	vim	2023-10-25
Ubuntu	USN-6453-1	20.04 22.04 23.04 23.10	xorg-server, xwayland	2023-10-25
Ubuntu	USN-6453-2	14.04 16.04 18.04	xorg-server	2023-10-31

Full Story (comments: none)