execute command by execvp() so can search command in PATH. 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
Yu Zhiguo
2010-Jul-21 07:11 UTC
Re: [Xen-devel] [PATCH] libxl: execute command by execvp()
Hi Ian, 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. 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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Jul-21 08:29 UTC
Re: [Xen-devel] [PATCH] libxl: execute command by execvp()
On Wed, 2010-07-21 at 08:11 +0100, Yu Zhiguo wrote:> Hi Ian, > > 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)? 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). 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?) 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 > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-Jul-21 11:59 UTC
Re: [Xen-devel] [PATCH] libxl: execute command by execvp()
On Wed, 21 Jul 2010, Yu Zhiguo wrote:> Hi Ian, > > Yu Zhiguo wrote: > > execute command by execvp() so can search command in PATH. > > > > It is trivial, but can you ack this fix?I have already applied your patch. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu Zhiguo
2010-Jul-22 02:46 UTC
Re: [Xen-devel] [PATCH] libxl: execute command by execvp()
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 >>> >>> >>> > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Jul-22 08:34 UTC
Re: [Xen-devel] [PATCH] libxl: execute command by execvp()
On Thu, 2010-07-22 at 03:46 +0100, Yu Zhiguo wrote:> 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").Yes, as I said I''m not sure how to make this non-racey ;-)> > 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?open(7) says this regarding O_NONBLOCK: Normally, opening the FIFO blocks until the other end is opened also. A process can open a FIFO in non-blocking mode. In this case, opening for read only will succeed even if no-one has opened on the write side yet; opening for write only will fail with ENXIO (no such device or address) unless the other end has already been opened. We would be opening the FIFO read-only and hence we shouldn''t meet the above problem. Once we get to bootloader_interact we will either wait in the select() until the exec is successful and stuff starts to happen or we get EOF on the PTY master because the slave has been closed when the child exits after failing to exec.> What about waitpid but no WNOHANG, we can catch the exit status of child > and check it.That would hang in the case where the child did exec successfully, or at least break user-interaction since we wouldn''t reach bootloader_interact in time for the user to do anything.> > 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...OK. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel