search for: will_write_block

...waitqueue. It may block forever? No, we enqueue then check: port = filp->private_data; poll_wait(filp, &port->waitqueue, wait); if (!port->guest_connected) { /* Port got unplugged */ return POLLHUP; } ret = 0; if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; if (!port->host_connected) ret |= POLLHUP; return ret; Which is the correct way to do this. Cheers, Rusty.

...waitqueue. It may block forever? No, we enqueue then check: port = filp->private_data; poll_wait(filp, &port->waitqueue, wait); if (!port->guest_connected) { /* Port got unplugged */ return POLLHUP; } ret = 0; if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; if (!port->host_connected) ret |= POLLHUP; return ret; Which is the correct way to do this. Cheers, Rusty.

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.

When removing a port we don't check if a program was blocked for read. This leads to a crash when SIGTERM is sent to the program after hot-unplugging the port. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/char/virtio_console.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c

When removing a port we don't check if a program was blocked for read. This leads to a crash when SIGTERM is sent to the program after hot-unplugging the port. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/char/virtio_console.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c

...cd41 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -710,7 +710,7 @@ static unsigned int port_fops_poll(struct file *filp, poll_table *wait) return POLLHUP; } ret = 0; - if (port->inbuf) + if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; -- 1.7.2.3

...cd41 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -710,7 +710,7 @@ static unsigned int port_fops_poll(struct file *filp, poll_table *wait) return POLLHUP; } ret = 0; - if (port->inbuf) + if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; -- 1.7.2.3

Hello, These patches are an initial attempt at supporting hibernation for virtio drivers. The default configuration of event_index=on doesn't work; i.e. restore from a hibernated image only works if the devices have event_index support turned off. I have not yet dug into this, but is most likely due to some state not being sync'ed. This could be related to the hack that is patch 3.

Hello, These patches are an initial attempt at supporting hibernation for virtio drivers. The default configuration of event_index=on doesn't work; i.e. restore from a hibernated image only works if the devices have event_index support turned off. I have not yet dug into this, but is most likely due to some state not being sync'ed. This could be related to the hack that is patch 3.

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

Amit Shah <amit.shah at redhat.com> writes: > On (Fri) 19 Jul 2013 [18:17:32], Jason Wang wrote: >> On 07/19/2013 03:48 PM, Amit Shah wrote: >> > On (Fri) 19 Jul 2013 [15:03:50], Jason Wang wrote: >> >> On 07/19/2013 04:16 AM, Amit Shah wrote: >> >>> Between poll() being called and processed, the port can be unplugged. >> >>> Check

Amit Shah <amit.shah at redhat.com> writes: > On (Fri) 19 Jul 2013 [18:17:32], Jason Wang wrote: >> On 07/19/2013 03:48 PM, Amit Shah wrote: >> > On (Fri) 19 Jul 2013 [15:03:50], Jason Wang wrote: >> >> On 07/19/2013 04:16 AM, Amit Shah wrote: >> >>> Between poll() being called and processed, the port can be unplugged. >> >>> Check

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