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

[Christian Brauner <brauner@kernel.org>]

On Fri, Nov 17, 2023 at 04:13:45PM +0100, Miklos Szeredi wrote:
> 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 limit for the number of mounts per mount namespace is set in
/proc/sys/fs/mount-max. It defaults to 100000. This value is globally
configured and thus can't be changed from e.g., unprivileged containers
but it applies to each mount namespace.

What glibc could do is read that value and cache the result and use that
as a hint or upper limit. That'll waste 800kb potentially but that could
be solved with a cache.

Alternatively you could add a basic listmount() glibc function and
another one that's explicitly there for handling large mount tables.