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: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers