Bug 1473605 - Include conditional_wakeup fix in glib2
Include conditional_wakeup fix in glib2
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glib2 (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Colin Walters
Desktop QE
Depends On: 1438539
Blocks: TRACKER-bugs-affecting-libguestfs
  Show dependency treegraph
Reported: 2017-07-21 05:36 EDT by Richard W.M. Jones
Modified: 2018-01-10 11:04 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1438539
: 1474405 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 761102 None None None 2017-07-21 05:36 EDT

  None (edit)
Description Richard W.M. Jones 2017-07-21 05:36:27 EDT
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 05:41:14 EDT
BTW we really need this fixed in RHEL 7.4-z.
Comment 4 Colin Walters 2017-07-21 09:04:16 EDT
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 12:56:55 EDT
No idea, but this affects qemu-kvm-1.5.3-141.el7_4.1.x86_64 right now.
Comment 6 Daniel Berrange 2017-07-24 05:11:07 EDT
The upstream commit is this one:

commit ecbddbb106114f90008024b4e6c3ba1c38d7ca0e
Author: Richard W.M. Jones <rjones@redhat.com>
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 09:55:05 EDT
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 09:59:59 EDT
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 10:15:12 EDT
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 10:16:03 EDT
Doesn't affect layered products.
Comment 11 Daniel Berrange 2017-07-24 10:25:50 EDT
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

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