Bug 1473605 - Include conditional_wakeup fix in glib2
Summary: Include conditional_wakeup fix in glib2
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glib2
Version: 7.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Colin Walters
QA Contact: Desktop QE
Depends On: 1438539
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
Reported: 2017-07-21 09:36 UTC by Richard W.M. Jones
Modified: 2021-01-15 07:40 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1438539
: 1474405 (view as bug list)
Last Closed: 2021-01-15 07:40:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 761102 0 Urgent RESOLVED Increase performance for main loop 2020-11-05 17:28:05 UTC

Description Richard W.M. Jones 2017-07-21 09:36:27 UTC
Description of problem:

Rebasing glib2 in RHEL 7.4 (bug 1386874) has introduced a bug
which affects the qemu main loop, originally reported in Fedora
in bug 1438539 (glib2) and bug 1435432 (qemu).

The bug causes the emulated ISA serial port in qemu to hang because
wakeup events get lost.

It's difficult to reliably reproduce this bug.  The best we have is
to run the following command:

  while libguestfs-test-tool -t 180 >& /tmp/log; do echo -n .; done

which should run forever (printing lots of dots), but where the bug
is present will sometimes fail, although often not for many iterations.

This bug can be fixed by backporting the following upstream commits:

    main: Create a helper function for "owner wakeup" optimization

    gmain: Signal wakeups if context has never been acquired as well

    gmain: only signal GWakeup right before or during a blocking poll

These commits cherry pick cleanly on top of glib2 2.50.3.  I have
built a scratch build containing the fix here:


Comment 2 Richard W.M. Jones 2017-07-21 09:41:14 UTC
BTW we really need this fixed in RHEL 7.4-z.

Comment 4 Colin Walters 2017-07-21 13:04:16 UTC
Weren't the qemu patches backported to RHEL?  If not, why not?

I asked upstream about this and it sounded like that was going to happen quickly.  Is the scenario here new base RHEL with old qemu?

Comment 5 Richard W.M. Jones 2017-07-21 16:56:55 UTC
No idea, but this affects qemu-kvm-1.5.3-141.el7_4.1.x86_64 right now.

Comment 6 Daniel Berrangé 2017-07-24 09:11:07 UTC
The upstream commit is this one:

commit ecbddbb106114f90008024b4e6c3ba1c38d7ca0e
Author: Richard W.M. Jones <rjones>
Date:   Fri Mar 31 21:51:33 2017 +0100

    main-loop: Acquire main_context lock around os_host_main_loop_wait.

This made it into the QEMU 2.9.0 release, and thus *is* present in qemu-kvm-rhev (that's used by RHEV and OpenStack).

It is *not*, however, present in the qemu-kvm 1.5.3 that is shipped in base RHEL, since that version doesn't rebase and no one backported the patch to it.

Comment 7 Colin Walters 2017-07-24 13:55:05 UTC
OK, well can we at least get a backport of that patch scheduled for 7.5 for qemu?

Comment 8 Colin Walters 2017-07-24 13:59:59 UTC
I'll move this bug to 7.5, and clone it for 7.4z if that decision is made.

Comment 9 Paolo Bonzini 2017-07-24 14:15:12 UTC
It's okay to backport the fix to RHEL.  All the previous discussions were centered around upstream and Fedora.

Comment 10 Paolo Bonzini 2017-07-24 14:16:03 UTC
Doesn't affect layered products.

Comment 11 Daniel Berrangé 2017-07-24 14:25:50 UTC
I opened this to request the QEMU fix be backported to qemu-kvm in 7.4.z  https://bugzilla.redhat.com/show_bug.cgi?id=1474405

Comment 17 Colin Walters 2018-05-16 21:16:57 UTC
The upstream bug is still a bit stalled: https://bugzilla.gnome.org/show_bug.cgi?id=761102

We could sync to what's in glib master today, but...since the qemu-kvm fix went out in https://bugzilla.redhat.com/show_bug.cgi?id=1473536 is it really worth the risk?  Let's just tell people to upgrade qemu?

Comment 20 RHEL Program Management 2021-01-15 07:40:08 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Note You need to log in before you can comment on or make changes to this bug.