>
> +/* cr_write_pipebuf - dump contents of a pipe/fifo (assume i_mutex taken) */
> +static int cr_write_pipebuf(struct cr_ctx *ctx, struct pipe_inode_info *pipe)
> +{
> + struct cr_hdr h;
> + void *kbuf, *addr;
> + int i, ret = 0;
> +
> + kbuf = (void *) __get_free_page(GFP_KERNEL);
this can sleep and inode->i_mutex is locked.
> + if (!kbuf)
> + return -ENOMEM;
> +
> + /* this is a simplified fs/pipe.c:read_pipe() */
> +
> + for (i = 0; i < pipe->nrbufs; i++) {
> + int nn = (pipe->curbuf + i) & (PIPE_BUFFERS-1);
> + struct pipe_buffer *pbuf = pipe->bufs + nn;
> + const struct pipe_buf_operations *ops = pbuf->ops;
> +
> + ret = ops->confirm(pipe, pbuf);
> + if (ret < 0)
> + break;
> +
> + addr = ops->map(pipe, pbuf, 1);
> + memcpy(kbuf, addr + pbuf->offset, pbuf->len);
> + ops->unmap(pipe, pbuf, addr);
> +
> + h.type = CR_HDR_BUFFER;
> + h.len = pbuf->len;
> + h.parent = 0;
> +
> + ret = cr_write_obj(ctx, &h, kbuf);
same here.
> + if (ret < 0)
> + break;
> + }
> +
> + free_page((unsigned long) kbuf);
> + return ret;
> +}
I think that cr_write_pipebuf() should be a service from fs/pipe.c. It
exposes a lot of pipe internals.
a 'dump' and 'restore' inode operations might be could solution to the
general problem of dumping and restoring inode contents. other file types
will have similar needs.
C.
_______________________________________________
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
