On Fri, 17 Nov 2023 at 15:47, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > The strings could get fairly large if they ever contain key material, > especially for post-quantum cryptography. A bit far fetched, but okay. > We have plenty of experience with these double-buffer-and-retry > interfaces and glibc, and the failure mode once there is much more data > than initially expected can be quite bad. For new interfaces, I want a > way to avoid that. At least as long applications use statmount_allloc, > we have a way to switch to a different interface if that becomes > necessary just with a glibc-internal change. Fair enough. And that brings us to listmount(2) where I'm less sure that the alloc+retry strategy is the right one. I still think that a namespace with millions of mounts is unlikely, but it's not completely out of the question. Also a listmount_alloc(3) API is less obvious since the mount ID array as well as its size needs to be returned. So I'm thinking whether it's a good idea to turn this into a open/list/.../close style of interface in libc? We could do that in the kernel as well, but I'm not sure it's worth it at this point. Thanks, Miklos
