All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhiguo <yuzg@cn.fujitsu.com>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] libxl: execute command by execvp()
Date: Thu, 22 Jul 2010 10:46:49 +0800	[thread overview]
Message-ID: <4C47B119.9040705@cn.fujitsu.com> (raw)
In-Reply-To: <1279700993.5872.1695.camel@zakaz.uk.xensource.com>

Ian Campbell wrote:
>> Yu Zhiguo wrote:
>>> execute command by execvp() so can search command in PATH.
>>>
>>  It is trivial, but can you ack this fix?
>>  Before this fix, when create guest, we must use absolute path
>> for bootloader, e.g. bootloader = "/usr/bin/pygrub".
>>  If not in absolute path now, xl create will block in:
>>
>>     pid = fork_exec_bootloader(&bootloader_fd, (char *)info->u.pv.bootloader, args);
>>  ...
>>     while (1) {
>>         fifo_fd = open(fifo, O_RDONLY); ------------> here
>>
>>  because pygrub cannot be executed so no data will be outputted into this fifo.
> 
> Hmm, perhaps we need some more error handling from fork_exec_bootloader,
> probably in addition to switching to execvp()? Perhaps a waitpid(..,..,
> WNOHANG) sometime before the fifo open to check the child hasn't gone
> away (although I'm not sure how oen makes this non-racey)?
> 

 Perhaps parent process goes to waitpid (with WNOHANG flag) but child
hasn't gone to execv("pygrub").

> Alternatively, maybe simply opening the FIFO O_NDELAY rather than using
> open+fcntl is sufficient stop stop us blocking here? I guess that would
> be safe since this is the read end of the FIFO. We would catch the
> bootloader failure (to exec or otherwise) later on in
> bootloader_interact (which either works already due to select returning
> EBADF or probably needs fixing to handle the bootloader failing
> regardless).
> 
 We can open fifo in NONBLOCK mode but I'm not sure we'll not meet
the above problem?
 What about waitpid but no WNOHANG, we can catch the exit status of child
and check it.

> Also, xend special cases the bare word "pygrub" and searches a specific
> list of likely install locations, perhaps libxl should duplicate that
> behaviour? (I think I prefer search $PATH to this but maybe consistency
> with previous behaviour trumps that?)

 I think search PATH is enough...

Yu

> 
> Ian.
> 
>> Yu
>>
>>> Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
>>>
>>> diff -r 12f0618400de -r da4c3756920e tools/libxl/libxl_exec.c
>>> --- a/tools/libxl/libxl_exec.c	Fri Jul 16 13:54:44 2010 +0100
>>> +++ b/tools/libxl/libxl_exec.c	Tue Jul 20 02:14:44 2010 +0800
>>> @@ -53,7 +53,7 @@
>>>      /* in case our caller set it to IGN.  subprocesses are entitled
>>>       * to assume they got DFL. */
>>>  
>>> -    execv(arg0, args);
>>> +    execvp(arg0, args);
>>>      _exit(-1);
>>>  }
>>>  
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>>
> 
> 
> 
> 
> 

  reply	other threads:[~2010-07-22  2:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-19 10:11 [PATCH] libxl: execute command by execvp() Yu Zhiguo
2010-07-21  7:11 ` Yu Zhiguo
2010-07-21  8:29   ` Ian Campbell
2010-07-22  2:46     ` Yu Zhiguo [this message]
2010-07-22  8:34       ` Ian Campbell
2010-07-21 11:59   ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C47B119.9040705@cn.fujitsu.com \
    --to=yuzg@cn.fujitsu.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.