Notices by Christian Brauner ?? (brauner@mastodon.social)

[1/5] One thing I keep coming back to is how rewarding and challenging it is to feel responsible for a wide variety of design decisions. That's a generic statement and applies to being a maintainer of any software project. Sure, some are bigger in scope like the Linux kernel or systemd.
Some projects have a much more visible exposure than others and we only get to know of the ones with less fame or notoriety when things break in ways we never imagined.

[4/5] I'm not really complaining. I'm just noticing that I'm aware of this responsibility and I try to live up to it as much as I can. But the human condition is failure and regression to the mean. Bug fixes are hard to do but easy to justify most of the time. For other developers they are also clear signals of value and work that someone put in. Features are another thing. They get the fame, they get the flame, and the blame.

[3/5] And the feedback is immediate and relentless exarcabeted by all fun "hacker websites" where people can harp on about things they're not really deeply involved in.

[2/5] Behind all these projects often is a small set of people that take decisions on how something works, looks like, feels, the "handiness" of the tool if you will. Getting to do that is a great pleasure and rewarding yet it's also fscking scary because you're the one who is on the hook when things break or don't live up to the expection of everyone.

[5/5] I love this work, I enjoy the responsibility, but if it would be less public I would probably miss it but I would also enjoy it.

I've started working on some glibc patches and while doing that I realized that glibc uses lore for their mailing list as well. And I'm super happy that b4 review tui that @monsieuricon built, works for glibc as well. That's really nice and gives me a unified review/tracking experience. Something that @codonell might also find useful.

The real tragedy about the ptrace bug is that @jann pointed to the exact exploit primitive in a 2020 patch series where he implemented the architecturally sound fix: keep the mm alive until the task is reaped.

But it neither got reviewed nor merged. Let's try and change that:

https://lore.kernel.org/20201016024019.1882062-1-jannh@google.com/

@jann Yeah, GitHub is aweful. I really love b4 review tui. Kernel review is now better than GitHub review tbh.

RE: https://mastodon.social/@daandemeyer/116144059697098766

I love that me ranting to @pid_eins about "I don't want to mount unprivileged images in the kernel so my idea is to do it in userspace relying on the new mount API through a daemon in systemd please come to LSFMM with me" turned out exactly as envisioned. And all in less than two years.

RE: https://mastodon.social/@brauner/116071424787849407

I took it one step further and implemented both CLONE_AUTOREAP (now for non-pidfd as well) and CLONE_PIDFD_AUTOKILL (requires no new privileges for the child now):

https://patch.msgid.link/20260223-work-pidfs-autoreap-v4-0-e393c08c09d1@kernel.org

RE: https://mastodon.social/@brauner/115871045863565861

So I've just been looking at the sponsorship page for LSFMM and you all need to go out and steal some of that AI funding money for one of the conferences that makes the compute for all the fanciness possible! Like right now, please.

RE: https://mastodon.social/@brauner/115871045863565861

The first and largest round of invites for the (V)FS track has been sent:

https://lore.kernel.org/all/20260225-aufeinander-kummervoll-1953a06beae9@brauner/

This includes everyone who would need a VISA. The next round will be smaller.

The video of my talk in the FOSDEM Kernel Devroom about new work in the filesystem layer has been published:

https://video.fosdem.org/2026/ua2114/B9JPLG-vfs_news.av1.webm

My role in upstream maintenance for the Linux Kernel will continue as it always has. The same goes for @pid_eins involvement in systemd. We take our upstream responsibility very seriously and always have.

I just sent out the CfP for LSF/MM/BPF 2026 in Zagreb, Croatia:

https://lore.kernel.org/20260110-lsfmm-2026-cfp-ae970765d60e@brauner

This year's committee is:

Javier González (Storage)
Martin K. Petersen (Storage)
Christian Brauner (Filesystems)
Amir Goldstein (Filesystems)
Jan Kara (Filesystems)
Vlastimil Babka (MM)
Matthew Wilcox (MM)
Daniel Borkmann (BPF)
Martin KaFai Lau (BPF)

Send us your proposals!

RE: https://mastodon.social/@brauner/115871045863565861

Be sure to request an invite to #lsfmmbpf 2026 in Zagreb, Croatia!

The #uapigroup hosts two brand new specifications at https://uapi-group.org/specifications

The VMClock specification comes from Amazon AWS and defines an efficient guest clock synchronization mechanism:
https://uapi-group.org/specifications/specs/vmclock/

The VMGenID specification defines a notification mechanism whenever a VM is cloned/copied so userspace and kernel can take appropriate action (e.g., changing machine ID or updating random seeds):
https://uapi-group.org/specifications/specs/vmgenid/

The #uapigroup is very happy to serve as a home for these specs.

The website for #LSFMM 2026 is up:
https://events.linuxfoundation.org/lsfmmbpf

LSFMM 2026 will take place in Zagreb, Croatia May 4 to May 6.

I have the privilege of acting as chair for this year and I'm very excited for one of the best conferences out there.

So PSA we are now not allowed to add Link: tags anymore unless they add information that is not in the commit message. @axboe has the receipts.

It's ok apparently to add a link to the merge message of a Multi-Patch series.

Might want to start spreading that word...
https://lore.kernel.org/CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com

#linux #kernel

@kernellogger @sven @vegard @monsieuricon But the links are useful independent of that. They simply provide a trivial jumping point to lore. If the series was managed via b4 it's trivial to back to all version of the same patchset.

The benefits for everyone else should simply be what counts here, not a perceived discomfort.