search for: __send_to_port

...port; struct scatterlist sg[1]; + void *data; + int ret; if (unlikely(early_put_chars)) return early_put_chars(vtermno, buf, count); @@ -1144,8 +1146,14 @@ static int put_chars(u32 vtermno, const char *buf, int count) if (!port) return -EPIPE; - sg_init_one(sg, buf, count); - return __send_to_port(port, sg, 1, count, (void *)buf, false); + data = kmemdup(buf, count, GFP_ATOMIC); + if (!data) + return -ENOMEM; + + sg_init_one(sg, data, count); + ret = __send_to_port(port, sg, 1, count, data, false); + kfree(data); + return ret; } /* -- 2.11.0

...port; struct scatterlist sg[1]; + void *data; + int ret; if (unlikely(early_put_chars)) return early_put_chars(vtermno, buf, count); @@ -1144,8 +1146,14 @@ static int put_chars(u32 vtermno, const char *buf, int count) if (!port) return -EPIPE; - sg_init_one(sg, buf, count); - return __send_to_port(port, sg, 1, count, (void *)buf, false); + data = kmemdup(buf, count, GFP_ATOMIC); + if (!data) + return -ENOMEM; + + sg_init_one(sg, data, count); + ret = __send_to_port(port, sg, 1, count, data, false); + kfree(data); + return ret; } /* -- 2.11.0

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

Hi Rusty, The linux-next kernel was failing my virtio-console test suite for a while. I looked into it today, and it's due to the virtqueue_add_buf() change that doesn't return > 0 values anymore. I found your commit that adjusts virtio_console.c, but you missed one instance where the return value mattered, and as a result not enough buffers were queued for the host to send in data.

Hi Rusty, The linux-next kernel was failing my virtio-console test suite for a while. I looked into it today, and it's due to the virtqueue_add_buf() change that doesn't return > 0 values anymore. I found your commit that adjusts virtio_console.c, but you missed one instance where the return value mattered, and as a result not enough buffers were queued for the host to send in data.

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

...t; Rename a jump label in init() > Rename jump labels in virtcons_probe() > Rename jump labels in add_port() > Rename a jump label in port_fops_open() > Rename a jump label in port_fops_splice_write() > Rename jump labels in port_fops_write() > Rename a jump label in __send_to_port() > Rename jump labels in alloc_buf() > Rename a jump label in five functions > > drivers/char/virtio_console.c | 155 ++++++++++++++++++++++++------------------ > 1 file changed, 87 insertions(+), 68 deletions(-) Would you like to take another look at change possibilities for...

...t; Rename a jump label in init() > Rename jump labels in virtcons_probe() > Rename jump labels in add_port() > Rename a jump label in port_fops_open() > Rename a jump label in port_fops_splice_write() > Rename jump labels in port_fops_write() > Rename a jump label in __send_to_port() > Rename jump labels in alloc_buf() > Rename a jump label in five functions > > drivers/char/virtio_console.c | 155 ++++++++++++++++++++++++------------------ > 1 file changed, 87 insertions(+), 68 deletions(-) Would you like to take another look at change possibilities for...

...r_out; + } sgl.n = 0; sgl.len = 0; @@ -953,12 +958,17 @@ static ssize_t port_fops_splice_write(struct pipe_inode_info *pipe, sgl.sg = buf->sg; sg_init_table(sgl.sg, sgl.size); ret = __splice_from_pipe(pipe, &sd, pipe_to_sg); + pipe_unlock(pipe); if (likely(ret > 0)) ret = __send_to_port(port, buf->sg, sgl.n, sgl.len, buf, true); if (unlikely(ret <= 0)) free_buf(buf, true); return ret; + +error_out: + pipe_unlock(pipe); + return ret; } static unsigned int port_fops_poll(struct file *filp, poll_table *wait)

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some