search for: wake_up_interrupt

Zhang, Xiantao wrote: >>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:49:57 +0800 > Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for > kvm/ia64. > > kvm_ia64.c is created to handle kvm ia64-specific core logic. > Signed-off-by: Xiantao Zhang

Zhang, Xiantao wrote: >>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:49:57 +0800 > Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for > kvm/ia64. > > kvm_ia64.c is created to handle kvm ia64-specific core logic. > Signed-off-by: Xiantao Zhang

...> 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: CPU1: unplug_port() >> >> if (!port->guest_connected) { >> return POLLHUP; >> } >>...

...> 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: CPU1: unplug_port() >> >> if (!port->guest_connected) { >> return POLLHUP; >> } >>...

...ueue, 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_connected) { return POLLHUP; } wake_up_interruptiable() poll_wait(filp, &port->waitqueue...

...ueue, 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_connected) { return POLLHUP; } wake_up_interruptiable() poll_wait(filp, &port->waitqueue...

...t file only on successful open" (Rusty) * remove patch 6, "fix race in port_fops_poll() and port unplug", (Rusty) * remove CC: stable from patches without reproducers v2 * add patch 11: Jason found a use-after-free in port unplug * patch 7 introduced a regression where the wake_up_interruptible was done before guest_connected and host_connected were set to false Amit Shah (9): virtio: console: fix race with port unplug and open/close virtio: console: fix race in port_fops_open() and port unplug virtio: console: clean up port data immediately at time of unplug virtio: conso...

...t file only on successful open" (Rusty) * remove patch 6, "fix race in port_fops_poll() and port unplug", (Rusty) * remove CC: stable from patches without reproducers v2 * add patch 11: Jason found a use-after-free in port unplug * patch 7 introduced a regression where the wake_up_interruptible was done before guest_connected and host_connected were set to false Amit Shah (9): virtio: console: fix race with port unplug and open/close virtio: console: fix race in port_fops_open() and port unplug virtio: console: clean up port data immediately at time of unplug virtio: conso...

...badness. I've marked these patches for stable@ as well. I went over the list twice to check if really each one should go to stable, and to me it looks like all are stable candidates. v2 * add patch 11: Jason found a use-after-free in port unplug * patch 7 introduced a regression where the wake_up_interruptible was done before guest_connected and host_connected were set to false Please review and apply, Amit Shah (11): virtio: console: fix race with port unplug and open/close virtio: console: fix race in port_fops_open() and port unplug virtio: console: clean up port data immediately at tim...

...badness. I've marked these patches for stable@ as well. I went over the list twice to check if really each one should go to stable, and to me it looks like all are stable candidates. v2 * add patch 11: Jason found a use-after-free in port unplug * patch 7 introduced a regression where the wake_up_interruptible was done before guest_connected and host_connected were set to false Please review and apply, Amit Shah (11): virtio: console: fix race with port unplug and open/close virtio: console: fix race in port_fops_open() and port unplug virtio: console: clean up port data immediately at tim...

...rt) spin_unlock_irq(&port->portdev->ports_lock); if (port->guest_connected) { + /* Let the app know the port is going down. */ + send_sigio_to_port(port); + + /* Do this after sigio is actually sent */ port->guest_connected = false; port->host_connected = false; - wake_up_interruptible(&port->waitqueue); - /* Let the app know the port is going down. */ - send_sigio_to_port(port); + wake_up_interruptible(&port->waitqueue); } if (is_console_port(port)) { -- 1.8.1.4

On 07/19/2013 04:16 AM, Amit Shah wrote: > Between poll() being called and processed, the port can be unplugged. > Check if this happened, and bail out. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/virtio_console.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/char/virtio_console.c

On 07/19/2013 04:16 AM, Amit Shah wrote: > Between poll() being called and processed, the port can be unplugged. > Check if this happened, and bail out. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/virtio_console.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/char/virtio_console.c

...onnected) { >>>>>> 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: CPU1: unplug_port() >>>> >>>> if (!port->guest_connected) { >>>> return POLLHUP...

...onnected) { >>>>>> 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: CPU1: unplug_port() >>>> >>>> if (!port->guest_connected) { >>>> return POLLHUP...

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

...NULL) { + rc = 3; /* not operational */ + kfree(inti); + goto unlock; + } + spin_lock_bh(&li->lock); + list_add_tail(&inti->list, &li->list); + atomic_set(&li->active, 1); + atomic_set_mask(CPUSTAT_EXT_INT, li->cpuflags); + if (waitqueue_active(&li->wq)) + wake_up_interruptible(&li->wq); + spin_unlock_bh(&li->lock); + rc = 0; /* order accepted */ +unlock: + spin_unlock_bh(&fi->lock); + VCPU_EVENT(vcpu, 4, "sent sigp emerg to cpu %x", cpu_addr); + return rc; +} + +static int __sigp_stop(struct kvm_vcpu *vcpu, u16 cpu_addr, int store) +{ +...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep + timeout instead of busy polling. Please review. Thanks Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use

fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell: > From: Matias Zabaljauregui <zabaljauregui at gmail.com> > > Impact: cleanup > > This patch allow us to use KVM hypercalls Something has broken in relation to this change. I'm not sure it is this change itself or one following, but I get the following error when using lguest: lguest: unhandled trap 6 at 0x418726