Re: [PATCH 3/4] vircommand: Make sysconf(_SC_OPEN_MAX) failure non-fatal
On Thu, Sep 12, 2024 at 03:31:38PM +0200, Martin Kletzander wrote:
On Wed, Aug 28, 2024 at 02:59:09PM +0200, Michal Prívozník wrote:
> On 8/28/24 14:39, Daniel P. Berrangé wrote:
> > On Wed, Aug 28, 2024 at 02:16:16PM +0200, Michal Privoznik wrote:
> > > The point of calling sysconf(_SC_OPEN_MAX) is to allocate big
> > > enough bitmap so that subsequent call to
> > > virCommandMassCloseGetFDsDir() can just set the bit instead of
> > > expanding memory (this code runs in a forked off child and thus
> > > using async-signal-unsafe functions like malloc() is a bit
> > > tricky).
> > >
> > > But on some systems the limit for opened FDs is virtually
> > > non-existent (typically macOS Ventura started reporting EINVAL).
> > >
> > > But with both glibc and musl using malloc() after fork() is safe.
> > > And with sufficiently new glib too, as it's using malloc() with
> > > newer releases instead of their own allocator.
> > >
I guess I'm out of the loop lately, could you point the possible readers
to the proof of the above? I'm hesitant to say this is fine due to the
virBitmapSetBitExpand() call.
Libvirt has relied on malloc-after-fork being safe, essentially,
forever. For a while this caused us to have problems on musl,
but musl maintainers eventually relented and made it safe too.
glib is hardcoded to use system malloc since before our minimum
glib version, and again we've relied on that ever since we adopted
use of glib.
So there's nothing new in what Michal writes above.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|