Re: proposed libc interface and man page for statmount(2)

Miklos Szeredi
2023-11-17T15:13:58Z

On Fri, 17 Nov 2023 at 15:47, Florian Weimer <fweimer@redhat.com> 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