search for: will_read_block

...ication 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 to be read, this patch fixes this by using the alredy defined will_read_block utility function 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://...

...ication 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 to be read, this patch fixes this by using the alredy defined will_read_block utility function 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://...

...>>> + } >>>>>>> poll_wait(filp, &port->waitqueue, wait); >>>>>>> >>>>>>> if (!port->guest_connected) { >>>>>> Looks still racy here. Unlike port_fops_read() which check >>>>>> will_read_block(). If unplug happens after the check but before the >>>>>> poll_wait(), caller will be blocked forever. >>>>> unplug_port() calls wake_up_interruptible on the waitqueue. >>>> I mean the following cases: >>> (formatting to fit properly:) >>...

...>>> + } >>>>>>> poll_wait(filp, &port->waitqueue, wait); >>>>>>> >>>>>>> if (!port->guest_connected) { >>>>>> Looks still racy here. Unlike port_fops_read() which check >>>>>> will_read_block(). If unplug happens after the check but before the >>>>>> poll_wait(), caller will be blocked forever. >>>>> unplug_port() calls wake_up_interruptible on the waitqueue. >>>> I mean the following cases: >>> (formatting to fit properly:) >>...

...t;> + return POLLHUP; >> >>> + } >> >>> poll_wait(filp, &port->waitqueue, wait); >> >>> >> >>> if (!port->guest_connected) { >> >> Looks still racy here. Unlike port_fops_read() which check >> >> will_read_block(). If unplug happens after the check but before the >> >> poll_wait(), caller will be blocked forever. >> > unplug_port() calls wake_up_interruptible on the waitqueue. >> >> I mean the following cases: > > (formatting to fit properly:) > >> >>...

...t;> + return POLLHUP; >> >>> + } >> >>> poll_wait(filp, &port->waitqueue, wait); >> >>> >> >>> if (!port->guest_connected) { >> >> Looks still racy here. Unlike port_fops_read() which check >> >> will_read_block(). If unplug happens after the check but before the >> >> poll_wait(), caller will be blocked forever. >> > unplug_port() calls wake_up_interruptible on the waitqueue. >> >> I mean the following cases: > > (formatting to fit properly:) > >> >>...

...However 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 to be read, this patch fixes this by using will_read_block(port) instead of the port->inbuf != NULL check. Signed-off-By: Hans de Goede <hdegoede at redhat.com> Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/char/virtio_console.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/virtio_c...

...However 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 to be read, this patch fixes this by using will_read_block(port) instead of the port->inbuf != NULL check. Signed-off-By: Hans de Goede <hdegoede at redhat.com> Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/char/virtio_console.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/virtio_c...

...te_data; > + if (!port->guest_connected) { > + /* Port was unplugged before we could proceed */ > + return POLLHUP; > + } > poll_wait(filp, &port->waitqueue, wait); > > if (!port->guest_connected) { Looks still racy here. Unlike port_fops_read() which check will_read_block(). If unplug happens after the check but before the poll_wait(), caller will be blocked forever.

...te_data; > + if (!port->guest_connected) { > + /* Port was unplugged before we could proceed */ > + return POLLHUP; > + } > poll_wait(filp, &port->waitqueue, wait); > > if (!port->guest_connected) { Looks still racy here. Unlike port_fops_read() which check will_read_block(). If unplug happens after the check but before the poll_wait(), caller will be blocked forever.

...* Port was unplugged before we could proceed */ >>> + return POLLHUP; >>> + } >>> poll_wait(filp, &port->waitqueue, wait); >>> >>> if (!port->guest_connected) { >> Looks still racy here. Unlike port_fops_read() which check >> will_read_block(). If unplug happens after the check but before the >> poll_wait(), caller will be blocked forever. > unplug_port() calls wake_up_interruptible on the waitqueue. I mean the following cases: CPU0: CPU1: unplug_port() if (!port->guest_con...

...* Port was unplugged before we could proceed */ >>> + return POLLHUP; >>> + } >>> poll_wait(filp, &port->waitqueue, wait); >>> >>> if (!port->guest_connected) { >> Looks still racy here. Unlike port_fops_read() which check >> will_read_block(). If unplug happens after the check but before the >> poll_wait(), caller will be blocked forever. > unplug_port() calls wake_up_interruptible on the waitqueue. I mean the following cases: CPU0: CPU1: unplug_port() if (!port->guest_con...

...ole ports virtio: console: Remove config work handler virtio: console: Move code around for future patches virtio: console: Use a control message to add ports virtio: console: Don't always create a port 0 if using multiport virtio: console: Rename wait_is_over() to will_read_block() virtio: console: Add support for nonblocking write()s virtio: console: Resize console port 0 on config intr only if multiport is off virtio: console: Store each console's size in the console structure virtio: console: Accept console size along with resize control messa...

...ole ports virtio: console: Remove config work handler virtio: console: Move code around for future patches virtio: console: Use a control message to add ports virtio: console: Don't always create a port 0 if using multiport virtio: console: Rename wait_is_over() to will_read_block() virtio: console: Add support for nonblocking write()s virtio: console: Resize console port 0 on config intr only if multiport is off virtio: console: Store each console's size in the console structure virtio: console: Accept console size along with resize control messa...

...ected) { > > + /* Port was unplugged before we could proceed */ > > + return POLLHUP; > > + } > > poll_wait(filp, &port->waitqueue, wait); > > > > if (!port->guest_connected) { > Looks still racy here. Unlike port_fops_read() which check > will_read_block(). If unplug happens after the check but before the > poll_wait(), caller will be blocked forever. unplug_port() calls wake_up_interruptible on the waitqueue. (But the wake_up should be done after guest_connected is set to false -- regression introduced in patch 7.) Amit

...d proceed */ > >>> + return POLLHUP; > >>> + } > >>> poll_wait(filp, &port->waitqueue, wait); > >>> > >>> if (!port->guest_connected) { > >> Looks still racy here. Unlike port_fops_read() which check > >> will_read_block(). If unplug happens after the check but before the > >> poll_wait(), caller will be blocked forever. > > unplug_port() calls wake_up_interruptible on the waitqueue. > > I mean the following cases: (formatting to fit properly:) > > CPU0:...

...OLLHUP; >>>>>> + } >>>>>> poll_wait(filp, &port->waitqueue, wait); >>>>>> >>>>>> if (!port->guest_connected) { >>>>> Looks still racy here. Unlike port_fops_read() which check >>>>> will_read_block(). If unplug happens after the check but before the >>>>> poll_wait(), caller will be blocked forever. >>>> unplug_port() calls wake_up_interruptible on the waitqueue. >>> I mean the following cases: >> (formatting to fit properly:) >> >>> CP...

...) on unplugging console ports virtio: console: Remove config work handler virtio: console: Move code around for future patches virtio: console: Use a control message to add ports virtio: console: Don't always create a port 0 if using multiport virtio: console: Rename wait_is_over() to will_read_block() virtio: console: Add support for nonblocking write()s drivers/char/virtio_console.c | 533 +++++++++++++++++++++------------------- include/linux/virtio_console.h | 18 +- 2 files changed, 288 insertions(+), 263 deletions(-)

...) on unplugging console ports virtio: console: Remove config work handler virtio: console: Move code around for future patches virtio: console: Use a control message to add ports virtio: console: Don't always create a port 0 if using multiport virtio: console: Rename wait_is_over() to will_read_block() virtio: console: Add support for nonblocking write()s drivers/char/virtio_console.c | 533 +++++++++++++++++++++------------------- include/linux/virtio_console.h | 18 +- 2 files changed, 288 insertions(+), 263 deletions(-)

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.