LWN: Comments on "The beginning of the 6.13 merge window"

bcachefs?

koverstreet — Fri, 22 Nov 2024 08:17:57 +0000

I suspect Jon would appreciate if we can keep this off the lwn pages for now.

I'm a little burned out on it anyways.

bcachefs?

burki99 — Fri, 22 Nov 2024 05:00:40 +0000

This time, it is not a late pull request but obnoxious behavior on the LKML: https://www.heise.de/news/Linus-Torvalds-suspendiert-Bcac...
Kent‘s own take (he has a hard time acknowledging behavioral issues, instead he prefers pointing out technical ones): https://www.patreon.com/posts/trouble-in-116412665
I am sure the editors could say much more. It seems to be a very unfortunate situation where technical innovation might fail to come to the kernel due to the inability of its author to respectfully listen and cooperate with his peers.

bcachefs?

jalla — Fri, 22 Nov 2024 01:14:24 +0000

There seemed to be a lot of noise around requests coming in at the 11th hour, this time around the pull request came in quite early. Curious to learn more about that this cycle.

Internal kernel changes - crypto subsystem

l1k — Thu, 21 Nov 2024 22:58:01 +0000

The kernel's cryptographic subsystem has gained a new internal API for signature generation. There is some kerneldoc documentation available.

Author here. More accurately the goal of my patches was to move sign/verify operations out of akcipher and into a new, separate crypto algorithm type. akcipher is thus now solely for asymmetric encrypt/decrypt. Of note here is that the new sign/verify API uses kernel buffers, whereas akcipher uses sglists.

Herbert Xu started the transition to the new crypto algorithm type for sign/verify a year ago by introducing a frontend:

https://lore.kernel.org/linux-crypto/ZIg4b8kAeW7x%2FoM1@gondor.apana.org.au/

I completed that effort by adding a backend and migrating all asymmetric sign/verify algorithms to it:

https://lore.kernel.org/all/cover.1725972333.git.lukas@wunner.de/

We currently have 3 algorithms in the tree: RSA (only PKCS1 encoding), ECDSA (X9.62 encoding and from v6.13 also P1363) and ECRDSA (aka GOST). Signing is currently only supported by the RSA algorithm implementation. Verifying by all three.

unlinkat flag?

josh — Thu, 21 Nov 2024 17:52:44 +0000

> There is a new sysctl knob, fs.dentry-negative, that controls whether the virtual filesystem (VFS) layer deletes a file's kernel-internal directory entry ("dentry") when the file itself is deleted. It seems that some benchmarks do better when dentries are removed, while others benefit from having a negative dentry left behind, so the kernel developers have put the decision into the system administrator's hands. The default value (zero) means that dentries are not automatically deleted, matching the behavior of previous kernels.

I wonder if it would make sense to add a flag to unlinkat, which lets userspace indicate on a case-by-case basis whether the removed file is likely to be looked for again or not? Userspace is in a great position to know whether a filename is likely to be looked for again or not.