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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux