Re: [PATCH 3/3] virGlobalInit: Make glib init its own global state

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

 



On Wed, Jun 21, 2023 at 5:30 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Wed, Jun 21, 2023 at 04:09:11PM +0200, Michal Privoznik wrote:
> > This should not be needed, but here's what's happening:
> > virStrToLong_*() family of functions was switched from strtol*()
> > to g_ascii_strtol*() in order to handle corner cases on Windows
> > (most notably parsing hex numbers with base=0) - see
> > v9.4.0-61-g2ed41d7cd9. But what we did not realize back then, is
> > the fact that g_ascii_strtol*() family has their own global lock
> > rendering virStrToLong_*() function unsafe between fork() +
> > exec(). Worse, if one of the threads has to wait for the lock (or
> > on its corresponding condition), then errno is mangled and
> > g_ascii_strtol*() signals an error, even though there's no error.
> >
> > Read more here:
> >
> >   https://gitlab.gnome.org/GNOME/glib/-/issues/3034
> >
> > Nevertheless, if we make glib init the g_ascii_strtol*() global
> > state (by calling one function from g_ascii_strtol*() family),
> > then there shouldn't be any congestion on the lock and thus no
> > errno mangling.
> >
> > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> > ---
> >  src/libvirt.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
>
> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>

Thanks, let me push this one, as it fixes both problems (daedlock and
string parse problem) and work on the other two next week as I'm going
AFK for the rest of the week. Jirka plans to freeze on Tuesday next
week but after this patch, close_range()/closefrom() is not that
critical.

Michal





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux