Bug 805533 - qemu-ga: possible race while suspending the guest
qemu-ga: possible race while suspending the guest
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.3
All Linux
high Severity high
: rc
: ---
Assigned To: Luiz Capitulino
Virtualization Bugs
:
Depends On:
Blocks: 804161 831387
  Show dependency treegraph
 
Reported: 2012-03-21 10:27 EDT by Luiz Capitulino
Modified: 2013-10-15 10:08 EDT (History)
11 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.307.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 02:33:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Luiz Capitulino 2012-03-21 10:27:41 EDT
During qemu-ga patch review it was found that there's a possible race in the code used to detect if the guest supports suspend. No suspend support could be erroneously reported when the race is triggered.

The code in question is in bios_supports_mode() function. Theoretically, the following calls could be interrupted if one of the children created by bios_supports_mode() exits - or other children created by qemu-ga, although no other code that could run in parallel with bios_supports_mode() does that today:

 close(pipefds[1]);
 g_free(pmutils_path);

 ret = read(pipefds[0], &status, sizeof(status));

The quick & easy solution for RHEL6.3 is to loop read() on EINTR error and block SIGCHLD during the close() and g_free() functions.

The Right solution for upstream is to add a general interface to create & safely wait for children to terminate. This would also simplify the suspend functions.
Comment 1 Ademar Reis 2012-04-09 19:53:37 EDT
Corner case on a tech-preview feature, postponing to 6.4.
Comment 2 Luiz Capitulino 2012-04-10 10:47:07 EDT
Took this upstream and the recommendation is to implement the easy fix:

  http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00998.html

This is doable for 6.3, but I agree it's a corner case.
Comment 3 Luiz Capitulino 2012-05-16 16:18:14 EDT
After some discussion, we decided to make the guest-suspend-* commands synchronous. This just drops the need for the SIGCHLD signal, which automatically ends up fixing this issue.

Patches submitted some days ago and already included in Michael Roth's latest pull request:

http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02093.html
Comment 10 Luiz Capitulino 2012-11-29 07:29:41 EST
As far as testing is concerned, this issue was found in code review and is theoretical. There's no recipe to trigger it. So I think verification should be skipped.
Comment 11 juzhang 2012-12-03 00:35:25 EST
Checked on qemu-kvm-0.12.1.2-2.337.el6, the codes indeed included according to changelog.

#rpm -q qemu-kvm-0.12.1.2-2.337.el6 --changelog | grep 805533
- Update information: Add bug 805533 information to changelog (fix for 827612 fixed also 805533)
- Resolves: bz#805533
Comment 13 errata-xmlrpc 2013-02-21 02:33:16 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0527.html
Comment 14 Qian Guo 2013-10-15 03:42:21 EDT
Hi, Luiz

Do we need  clone this bug to RHEL7 product?

Thanks
Comment 15 Luiz Capitulino 2013-10-15 10:08:22 EDT
No, this is a very old issue fixed since qemu v1.1.0, but thanks for checking.

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