This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] Fix bootloader handling when empty string is being o

To: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] Fix bootloader handling when empty string is being output
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Mon, 30 Aug 2010 15:10:02 +0200
Delivery-date: Mon, 30 Aug 2010 06:10:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
this is the patch to fix empty string as the output value
of the bootloader string. If there is no output then
xend is being hung indefinitely unless you press Ctrl + C keys
to trigger SIGINT. This patch fixes the issue by implementing
timeout to the select() function for reading from pipe and also
checking for state of the process - i.e. whether the process is
running or whether it's dead or zombie (because fork() call does
leave zombies when the process is done but the parent process is
still running).

I tried it with the bogus bootloader that just returns with
error code 0 and also the bogus bootloader that sleeps for 10
seconds and then returns with error code 0. According to my
testing when the bootloader process has finished and the output
of the process is empty it fails with "bootloader didn't return
any data" message which is the expected behaviour. This patch
has also been tested with the various timeout values (incl. no
timeout specified) for pyGrub and everything was working fine
since it was failing *only* in the case both output from pyGrub
was empty and the bootloader process was not running according
the pid.

The check for bootloader running is implemented by checking
the presence of /proc/{$PID} and also state in the stat file

Testing: The patch has been tested on RHEL-5.5 x86_64 dom0 with
RHEL-5.4 PV guest both with good and bad bootloader setup. By bad
bootloader I mean just the shell script exiting with code 0 and
also shell script sleeping for 10 seconds and exiting with code 0.
Before my patch applied it got stuck indefinitely in the xend
because of waiting for some data on select() call and after my
patch applied it's opening the FIFO with O_NDELAY and tries to
read the data indefinitely every second using the select() call
with 1 second as the timeout argument. If there were no data
output using the read call it just fails after the child
(bootloader) process exited. Otherwise, when bootloader did
return some data, the guest started successfully no matter
what the timeout was defined in pyGrub.

Signed-off-by: Michal Novotny <minovotn@xxxxxxxxxx>


Michal Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat

Attachment: fix-bootloader-empty-output-handling.patch
Description: Text Data

Xen-devel mailing list