> > +/* 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 Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers