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

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

I think we're slowly seeing the severe implications of AI coding slop creeping up. In the last 24 hours we have received a bunch of bug reports (against non-upstream kernels even) on fsdevel that are almost guaranteed to be generated by some bot.

In addition we seem to be getting really strange security@kernel.org reports that report normal system behavior as security vulnerabilities.

I can't wait for the next 6 months...

I've done a series that adds support for AF_UNIX sockets in coredumps. Userspace provides an AF_UNIX socket path via core_pattern and the kernel connects to it, shuts down the read side and writes the coredump to the socket.

This means no more super privileged usermode helper upcalls and makes for a very nice API experience. I captured coredumps simply via socat:

https://lore.kernel.org/20250430-work-coredump-socket-v1-0-2faf027dbb47@kernel.org

The receiver can use SO_PEERPIDFD to get a stable handle on the crashed process.

#kernel #linux #coredump

1/n

Oh yeah, I already mentioned this a while ago but I also added support for pidfds in Linux coredumps.

/proc/sys/kernel/core_pattern has been extended so userspace can instruct the kernel to install a pidfd for the
crashing process into the usermode helper process, e.g., systemd-coredump.

Replaced sudo with run0 and I'm very happy to have one less setuid binary to worry about.

#systemd #Linux

Picked back up the work for VFS {g,u}id squashing. IOW, mapping all {g,u}ids down to a single {g,u}id. Any process that doesn't have that {g,u}id but is still privileged otherwise will write to disk as the squashed {g,u}id. I just finished a draft and selftests that miraculously work.

https://web.git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=work.idmapped.squash

Probably "bugs galore" at this point. Needs more thinking.

#linux #kernel #vfs #filesystems

I think multi-threaded exec behavior needs to be illegal:
https://web.git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs-6.15.pidfs&id=3ae8576617e88a2b3cdbad6d8087be3454a4b326

de_thread() is an insult to humanity.

https://lwn.net/Articles/1010667

I want this for struct file allocations.

We've removed #reiserfs and now we're removing #sysv https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs-6.15.sysv

The code removal continues.

#kernel #linux #fs

@osandov 🤡

@axboe @osandov This was actually the first time I ever read Phoronix comments. Immediately regretted it.

@osandov you already made it to Phoronix.
https://www.phoronix.com/news/Linux-6.14-Faster-kcore-Reads

util-linux has merged support for statmount() and listmount() to list mounts:
https://github.com/util-linux/util-linux/pull/3092#event-15865684400

This should be a nice performance improvement.

See https://brauner.io/2024/12/16/list-all-mounts.html for some details on listmount() and statmount().

#linux #kernel