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

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

 



* Miklos Szeredi:

> On Thu, 16 Nov 2023 at 21:36, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>
>> In addition to Adhemerval's observation that we'd prefer to have some
>> hint regarding the buffer size, it's probably better to have entirely
>> separate interfaces because it makes static analysis easier.  With a
>> unified interface, we can still convey the information with an inline
>> wrapper function, but we can avoid that complexity.
>
> I'm not against having separate allocating and the non-allocating
> interfaces.

Thanks.

> But I don't think the allocating one needs a size hint.   Your
> suggestion of passing a buffer on the stack to the syscall and then
> copying to an exact sized malloc should take care of it.   If the
> stack buffer is sized generously, then the loop will never need to
> repeat for any real life case.

The strings could get fairly large if they ever contain key material,
especially for post-quantum cryptography.

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.

Thanks,
Florian





[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