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

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.

@kernellogger @sven @vegard @monsieuricon I do that religiously as well. Every multi-patch series gets a merge commit (forwardable or not).

@kernellogger @sven @vegard @monsieuricon The other thing is: Either make it official policy that you don't want to see any Links in the commit messages or just accept that some people do and some people don't. But if you make it a policy then document it somewhere, please.

@kernellogger @sven @vegard @monsieuricon and how a simple request did spiral into a philosophical discussion of this dimension is a bit beyond me as well. We could've just ended this with "I personally don't like the links. If others find them useful then great but please don't try to convince others to add them." End of story, everyone is happy and can move on.

@jann The real culprit here is coredumps in a way.

Honestly, I'm prepared to start a kickstarter for whatever amount of money it takes for someone to port Linux man-pages from groff to markdown.

@cyphar is doing the important work as usual

https://lore.kernel.org/20250807-new-mount-api-v2-0-558a27b8068c@cyphar.com

but groff must be one of the original sins. Like, Moses came down from the mountain and was like "don't do groff" but accidently dropped the first stone table or something. Like seriously, everytime I have to look at patches I die a little inside.

I love how Apple will now be repeating every goddman security mistake by writing their own container runtime. I thought we're past all that but hey, let's have some more path lookup CVEs. @cyphar

https://github.com/apple/containerization/pull/173