On the radar: the ongoing, slow-burning discussion over the sched_ext scheduling class (which allows the writing of complete CPU schedulers in BPF: https://lwn.net/Articles/922405/). This thread has been ongoing since July:

https://lwn.net/ml/linux-kernel/20230726091752.GA3802077@hirez.programming.kicks-ass.net/

with a new message showing up every few weeks. Regardless of how one feels about sched_ext, it is clear that quite a bit of thought has gone into the problem on both sides of the debate.

On the radar: improved tunable handling for glibc. The recent vulnerability has drawn their attention to this aspect of library behavior, and now they are trying to make some changes to prevent the next vulnerability before it happens (or at least before somebody finds it)

https://lwn.net/ml/libc-alpha/20231010180111.561793-1-adhemerval.zanella@linaro.org

So they made a movie about my dad ...

https://fullcirclefilm.co/

...and about a crazy kid named Trevor Kennison and how both recovered their lives after a devastating injury. I've seen it, it's definitely worth a watch. The site lists a lot of upcoming screenings (all just in North America, alas).

So OSS Europe was an interesting experience, this year, in a way.

I did my usual talk, and started with the usual section on kernel releases. When talking about stable updates I tossed in a quick mention that six-year support from the stable team was being phased out — something I understood to be generally known for about the last year. Way at the end of the talk, as my last topic, I discussed at some length the stresses being felt by kernel maintainers.

@sjvn wrote an article about the talk (https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be-cut-as-maintainence-remains-under-strain/) and made a connection between the stable-policy change and the maintainer issue — something I had not done in the talk. It was a bit of a shift from what I said, but not a bad article overall.

Then the rest of the net filled up with other writers putting up articles that were clearly just cribbed from SJVN's piece — sometimes with credit, sometimes without. I'm getting emails about what a terrible idea this all is, as if I had anything to do with that decision or can somehow change it. I have, it seems, taken away everybody's six-year support, and they're not happy about it.

All because of a 30-second mention of a change that was made public something like a year ago. My 1.5 minutes of fame has given me a new appreciation for this old quote from Rusty Russell: "when a respected information source covers something where you have on-the-ground experience, the result is often to make you wonder how much fecal matter you've swallowed in areas outside your own expertise."

On the radar: reconsidering the kernel's preemption models.

It all started in a discussion on optimizing string operations on x86, but that led to finding ways to allow preemption for long-running operations even in non-preempable kernels.

You see, the kernel offers a number of different models for when kernel code itself can be preempted to run something with a higher priority. All the way from PREEMPT_NONE (no preemption at all) through PREEMPT_VOLUNTARY (preemption at explicitly marked points) and plain PREEMPT (anytime not in a critical section) through to PREEMPT_RT for realtime. Linus was getting grumpy about the scattering of voluntary preemption points, and eventually came around to the idea of maybe dropping PREEMPT_NONE and PREEMPT_VOLUNTARY altogether:

https://lwn.net/ml/linux-kernel/CAHk-=whpYjm_AizQij6XEfTd7xvGjrVCx5gzHcHm=2Xijt+Kyg@mail.gmail.com/

I doubt that's going to happen, but we may see a reduction of options in favor of PREEMPT_DYNAMIC, which allows choosing between voluntary and full preemption at boot time.

Well, vger (as of right now) no longer directly attempts to deliver to gmail/google/googlemail just to get the ridiculous backlog out of the primary mail paths. Vger (1 machine) is kicking all of that queue over to 8 other machines and letting them go try to get that delivered and queue up somewhere where it's not going to cause everyone else pain.

This should, at least for now, settle out several things, but if you are seeing mail wonkiness give postmaster@ a ping and I'll take a look.

Also if you are on Gmail and doing kernel dev, might be worth looking at other email providers.

On the radar: restricting access to "ALTER SYSTEM" in postgresql

Having mutually untrusting users connecting to the same postgresql server is a tricky proposition from the beginning; it's even moreso if, for some reason, some of those users are postgresql superusers. There is a proposal to chip away one piece of the problem by making it possible to disable the ALTER SYSTEM command, which affects global server parameters:

https://lwn.net/ml/pgsql-hackers/CA+VUV5rEKt2+CdC_KUaPoihMu+i5ChT4WVNTr4CD5-xXZUfuQw@mail.gmail.com/

There is disagreement over whether this is a piece of security theater or a useful option for some providers.

On the radar: advancing the Git SHA-256 work.

Moving Git away from the SHA1 hash has been a long and slow process:

https://lwn.net/Articles/898522/

Much of the basic support to use SHA-256 is there, but a lot of the finishing work is not, so it remains unused. Now Eric Biederman has surfaced with a set of patches to provide interoperability between SHA-1 and SHA-256 repositories:

https://lwn.net/ml/git/87sf7ol0z3.fsf@email.froward.int.ebiederm.org/

Someday, maybe, this transition will actually happen. Maybe.

On the radar: git replay and jj

The git community is considering a "replay" command as a variant of rebase:

https://lwn.net/ml/git/20230907092521.733746-1-christian.couder@gmail.com/

As I was reading through the description, I saw that one of the motivations for this work is "jj is slaughtering us on rebase speed". Not being familiar with jj or its murderous speed, I dug and found:

https://github.com/martinvonz/jj

Google, it seems, has put a full-time developer on creating an alternative to git.

On the radar: maintainers summit discussion about keeping old, unmaintained filesystems in the kernel:

https://lwn.net/ml/ksummit-discuss/ZO9NK0FchtYjOuIH@infradead.org/

The kernel has a "no regressions" rule, and it's hard to argue that removing a filesystem that has users is not a regression. But there are also limits to how long some of those filesystems can be carried forward.

I looked at one aspect of this back in July (https://lwn.net/Articles/939097/), but the discussion seems destined to continue for a while yet.

Still, should this topic show up at the actual maintainers summit, I'm guessing Linus would stop it short by saying "we don't remove code that people are using; next topic".

On the radar: the 6.6 bcachefs discussion:

https://lwn.net/ml/linux-kernel/20230903032555.np6lu5mouv5tw4ff@moria.home.lan/

It turns out that if you ask to merge a big new subsystem that hasn't even been seen in linux-next, Linus gets grumpy with you.

On the radar: replacing openSUSE Leap:

https://lwn.net/ml/opensuse-factory/c9df1be1a23ad815393acb1797d0f9bf1f007e89.camel@suse.de/

"Slowroll" for the win?

On the radar: passim in Fedora

https://lwn.net/ml/fedora-devel/CAD2FfiHV5_kd72Xc1t-=V_EtqBiiKZ7=8Uke5k3FZeLcZOJ9Mw@mail.gmail.com/

Passim, it seems, is an mDNS-based system for sharing firmware updates across a local net. The idea is to help firmware distribution scale up, but it might also increase the attack surface of systems in interesting ways.

It has happened at last: after many iterations, that x86 shadow-stack patch series has been accepted into the mainline for 6.6:

https://lwn.net/ml/linux-kernel/CAHk-=wipDVFEfSJxbnUSDqENs5i8RzSsgJOFdb69pH=b7BOFiQ@mail.gmail.com/

For those who haven't been following this saga, see https://lwn.net/Articles/926649/

On the radar: tossing out the Debian /usr merge and start over.

I've been watching this for a week or so...Debian developer Ian Jackson has declared that the project's current approach to its interminable /usr-merge effort was mistaken from the beginning:

https://lwn.net/ml/debian-ctte/25823.5706.112593.999861@chiark.greenend.org.uk/

He proposes backing the whole thing out (on the entire installed Debian user base) and trying again with a symlink-farm approach.

Need I say that he has not found an immediate consensus on this?

On the radar: moving the GNU C Library to Linux Foundation hosting.

The whole issue of moving the GNU toolchain projects out of Sourceware and into an LF project was covered here a year ago:

https://lwn.net/Articles/908638/

Since then it has been mostly quiet. Now, though, there seems to be a move afoot to actually make the move for glibc. It is hard to say for sure, since (as seems to be typical), the discussion is being held entirely behind closed doors, though it has now been pushed onto the glibc-alpha list:

https://lwn.net/ml/libc-alpha/orsf805tyf.fsf@lxoliva.fsfla.org/

I do not think that having the LF handle this infrastructure is necessarily a bad idea; the people there are (seriously) good and it has been hugely beneficial to the kernel project. But the handling of the idea remains horrible; it looks like a hostile takeover and could do real damage to the community.

On the radar: user namespaces as a way to bypass negative permissions:

https://lwn.net/ml/linux-fsdevel/20230829205833.14873-1-richard@nod.at/

Not that this is new; I wrote about it a couple of years ago:

https://lwn.net/Articles/855943/

On the radar: PostgreSQL 16

The first release candidate is about to come out:

https://lwn.net/ml/pgsql-hackers/09b26b72-8ce6-83bf-8449-6a89621ddfa6@postgresql.org/

general release expected in mid-September.

On the radar: shrinking the Emacs C core

Another one of those "I'm Eric Raymond and I'm here to help you" moments:

https://lwn.net/ml/emacs-devel/20230809094655.793FC18A4654@snark.thyrsus.com/

He showed up on the Emacs list wanting to thrash up much of the core editor code for some secret project that he didn't want to tell anybody about... the reaction was about as might have been expected. It did, though, kick off an extensive discussion on how much of the editor should be implemented in Lisp and whether moving C code to Lisp makes sense.

On the radar: GCC security policy

I want to try a little experiment here. As I spend my day screwing around on the net, I come across a lot of conversations that may or may not eventually make good LWN articles. I'll toss one of those out here occasionally and see if people find it useful. Appearance here does not mean that I will (or will not) write something about it later, only that it has caught my attention.

The first topic is a few weeks old but still possibly interesting: the GCC folks are working to hammer out a security policy, which comes down to laying out what does — or does not — constitute a GCC security bug:

https://lwn.net/ml/gcc-patches/CAGWvny=z1yotE-6geJL1j80qSeZU67h-ZENPowM=BSNm0nHOVA@mail.gmail.com/

Strangely enough, it turns out that if you feed untrusted source to the compiler and the result bites you, they don't think it's a compiler bug.