OL> +/* restore a pipe */
OL> +static int
OL> +cr_read_fd_pipe(struct cr_ctx *ctx, struct cr_hdr_fd_data *hh, int rparent)
OL> +{
OL> + struct file *file;
OL> + int fds[2], which, ret;
OL> +
OL> + file = cr_obj_get_by_ref(ctx, hh->fd_objref, CR_OBJ_FILE);
OL> + if (IS_ERR(file))
OL> + return PTR_ERR(file);
OL> + else if (file)
OL> + return cr_attach_get_file(file);
OL> +
OL> + /* first encounter of this pipe: create it */
OL> + ret = do_pipe(fds);
OL> + if (ret < 0)
OL> + return ret;
OL> +
OL> + which = (hh->f_flags & O_WRONLY ? 1 : 0);
OL> +
OL> + /*
OL> + * Below we return the fd corersponding to one side of the pipe
OL> + * for our caller to use. Now register the other side of the pipe
OL> + * in the hash, to be picked up when that side is to be restored.
OL> + */
OL> + file = cr_obj_add_file(ctx, fds[1-which], hh->fd_objref);
OL> + if (IS_ERR(file)) {
OL> + ret = PTR_ERR(file);
OL> + goto out;
OL> + }
OL> +
OL> + ret = cr_read_pipe(ctx, fds[which]);
OL> + out:
OL> + sys_close(fds[1-which]); /* this side isn't used anymore */
This isn't always a valid thing to do, right? I can think of two
scenarios off the top of my head that will break here:
1. The process has called pipe() but has not yet fork()'d
2. The process is using both sides of a pipe for a select()-based
event loop
I worked up a quick test for #1, and it dies immediately on restart
with a SIGPIPE.
I'll see if I can work up and post a patch to fix this if I can come
up with something I think is reasonable.
Thanks!
--
Dan Smith
IBM Linux Technology Center
email: da...@us.ibm.com
_______________________________________________
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
