On Wed, Feb 03, 2010 at 10:27:32AM -0500, Laine Stump wrote:
> These functions have the same potential problem that Cole found in
> virExec - if the log mutex is currently held at the time of the fork,
> the child process' logging mutex will be locked, but nobody in the
> process to unlock it. If the child process tries to log anything, it
> will wait forever for this lock. The solution is to have the parent
> acquire the lock before fork, then both parent and child release the
> lock right after.
>
> Note that this patch requires Cole's patch to be applied first.
> ---
> src/util/util.c | 12 ++++++++++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/util/util.c b/src/util/util.c
> index 901c0d2..d8a2394 100644
> --- a/src/util/util.c
> +++ b/src/util/util.c
> @@ -1263,7 +1263,11 @@ int virFileCreate(const char *path, mode_t mode,
> * following dance avoids problems caused by root-squashing
> * NFS servers. */
>
> - if ((pid = fork()) < 0) {
> + virLogLock();
> + pid = fork();
> + virLogUnlock();
> +
> + if (pid < 0) {
> ret = errno;
> virReportSystemError(NULL, errno,
> _("cannot fork o create file '%s'"), path);
> @@ -1369,7 +1373,11 @@ int virDirCreate(const char *path, mode_t mode,
> return virDirCreateSimple(path, mode, uid, gid, flags);
> }
>
> - if ((pid = fork()) < 0) {
> + virLogLock();
> + pid = fork();
> + virLogUnlock();
> +
> + if (pid < 0) {
> ret = errno;
> virReportSystemError(NULL, errno,
> _("cannot fork to create directory '%s'"),
Okay, makes sense, ACK, and applied !
Maybe at some point a wrapper around fork() may be nicer.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list