search for: port_has_data

...ilp, char __user *ubuf, > > port = filp->private_data; > > + /* Port is hot-unplugged. */ > + if (!port->guest_connected) > + return -ENODEV; > + What if the port is hot-unplugged after this check? Should we serialize the hot plug with inbuf_lock here? > if (!port_has_data(port)) { > /* > * If nothing's connected on the host just return 0 in > @@ -765,7 +769,7 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, > if (ret < 0) > return ret; > } > - /* Port got hot-unplugged. */ > + /* Port got hot-unplu...

...ilp, char __user *ubuf, > > port = filp->private_data; > > + /* Port is hot-unplugged. */ > + if (!port->guest_connected) > + return -ENODEV; > + What if the port is hot-unplugged after this check? Should we serialize the hot plug with inbuf_lock here? > if (!port_has_data(port)) { > /* > * If nothing's connected on the host just return 0 in > @@ -765,7 +769,7 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, > if (ret < 0) > return ret; > } > - /* Port got hot-unplugged. */ > + /* Port got hot-unplu...

...ilp->private_data; > > > > + /* Port is hot-unplugged. */ > > + if (!port->guest_connected) > > + return -ENODEV; > > + > > What if the port is hot-unplugged after this check? Should we serialize > the hot plug with inbuf_lock here? If that happens, port_has_data() returns false, and the later functions return appropriately, as unplug_port() clears out all the data. However, I spotted a couple of things that need fixing: 1. In the condition you describe above, port_has_data will return false, and host_connected will be false as well, and fops_read() will...

...er if an application reads enough bytes from inbuf through port_fops_read, to empty the current port->inbuf, port->inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data ready to be read, this patch fixes this by using port_has_data(port) instead of the port->inbuf != NULL check. Signed-off-By: Hans de Goede <hdegoede at redhat.com> Regards, Hans -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6.35.4-virtio_console-fix-poll.patch Url: http://lists.linu...

...er if an application reads enough bytes from inbuf through port_fops_read, to empty the current port->inbuf, port->inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data ready to be read, this patch fixes this by using port_has_data(port) instead of the port->inbuf != NULL check. Signed-off-By: Hans de Goede <hdegoede at redhat.com> Regards, Hans -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linux-2.6.35.4-virtio_console-fix-poll.patch Url: http://lists.linu...

...02a 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -749,6 +749,10 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, port = filp->private_data; + /* Port is hot-unplugged. */ + if (!port->guest_connected) + return -ENODEV; + if (!port_has_data(port)) { /* * If nothing's connected on the host just return 0 in @@ -765,7 +769,7 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, if (ret < 0) return ret; } - /* Port got hot-unplugged. */ + /* Port got hot-unplugged while we were waiting above. */ i...

...075 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -749,6 +749,10 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, port = filp->private_data; + /* Port is hot-unplugged. */ + if (!port->guest_connected) + return -ENODEV; + if (!port_has_data(port)) { /* * If nothing's connected on the host just return 0 in @@ -765,7 +769,7 @@ static ssize_t port_fops_read(struct file *filp, char __user *ubuf, if (ret < 0) return ret; } - /* Port got hot-unplugged. */ + /* Port got hot-unplugged while we were waiting above. */ i...

Hi All, I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there.

Hi All, I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there.

...o return the amount of data we wrote */ - return buf->len; + return len; } /* @@ -461,26 +436,25 @@ static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count, bool to_user) { struct port_buffer *buf; - ssize_t ret; unsigned long flags; if (!out_count || !port_has_data(port)) return 0; buf = port->inbuf; - if (out_count > buf->len - buf->offset) - out_count = buf->len - buf->offset; + out_count = min(out_count, buf->len - buf->offset); if (to_user) { + ssize_t ret; + ret = copy_to_user(out_buf, buf->buf + buf->offset,...

...o return the amount of data we wrote */ - return buf->len; + return len; } /* @@ -461,26 +436,25 @@ static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count, bool to_user) { struct port_buffer *buf; - ssize_t ret; unsigned long flags; if (!out_count || !port_has_data(port)) return 0; buf = port->inbuf; - if (out_count > buf->len - buf->offset) - out_count = buf->len - buf->offset; + out_count = min(out_count, buf->len - buf->offset); if (to_user) { + ssize_t ret; + ret = copy_to_user(out_buf, buf->buf + buf->offset,...

Hi Rusty, The main thing in these patches is the introduction of injecting SIGIO on host-side connect/disconnect events and when new data is available for ports. The first two patches fix bugs that I haven't seen, but look like the right thing to do. These have been tested extensively using the test-virtserial test suite. Please apply, Amit. Amit Shah (4): virtio: console: Un-block

Hi Rusty, The main thing in these patches is the introduction of injecting SIGIO on host-side connect/disconnect events and when new data is available for ports. The first two patches fix bugs that I haven't seen, but look like the right thing to do. These have been tested extensively using the test-virtserial test suite. Please apply, Amit. Amit Shah (4): virtio: console: Un-block

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform