search for: task_run

...ings go a bit funny. So for instance; if in ccw_io_helper() we expect that wait_event(, !doing_io()) to be (mostly) true on first go, then we'll never get into __wait_event() and ->state won't actually be mucked about with. The thing to avoid is not actually sleeping (much) but setting TASK_RUNNING and turning the entire thing into a giant poll loop.

...fig is blocking - it's waiting > for a hardware interrupt. > > And it makes sense: config is not data path, I don't think > we should spin there. > > So I think besides these two parts, we still need my two patches: > virtio-balloon: do not call blocking ops when !TASK_RUNNING > virtio_console: avoid config access from irq > in 4.0. > > agree? I agree that we need those fixes as well.

...onfig is blocking - it's waiting > for a hardware interrupt. > > And it makes sense: config is not data path, I don't think > we should spin there. > > So I think besides these two parts, we still need my two patches: > virtio-balloon: do not call blocking ops when !TASK_RUNNING I prefer to annotate, over trying to fix this. Because it's not important. We might spin a few times, but it's very unlikely, and it's certainly not performance critical. Thanks, Rusty. Subject: virtio_balloon: annotate possible sleep waiting for event. CCW (s390) does this....

...ings go a bit funny. So for instance; if in ccw_io_helper() we expect that wait_event(, !doing_io()) to be (mostly) true on first go, then we'll never get into __wait_event() and ->state won't actually be mucked about with. The thing to avoid is not actually sleeping (much) but setting TASK_RUNNING and turning the entire thing into a giant poll loop.

...fig is blocking - it's waiting > for a hardware interrupt. > > And it makes sense: config is not data path, I don't think > we should spin there. > > So I think besides these two parts, we still need my two patches: > virtio-balloon: do not call blocking ops when !TASK_RUNNING > virtio_console: avoid config access from irq > in 4.0. > > agree? I agree that we need those fixes as well.

...onfig is blocking - it's waiting > for a hardware interrupt. > > And it makes sense: config is not data path, I don't think > we should spin there. > > So I think besides these two parts, we still need my two patches: > virtio-balloon: do not call blocking ops when !TASK_RUNNING I prefer to annotate, over trying to fix this. Because it's not important. We might spin a few times, but it's very unlikely, and it's certainly not performance critical. Thanks, Rusty. Subject: virtio_balloon: annotate possible sleep waiting for event. CCW (s390) does this....

...set_config are expected to fail. Cornelia, I think ccw and config_area should be allocated inside vcdev. You could either use pointers, or simply allocate vcdev with GDP_DMA. This would avoid the kmalloc inside these calls. Thanks, Rusty. > > [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at > [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 > [ 0.839694] ------------[ cut here ]------------ > [ 0.839697] WARNING: at kernel/sched/core.c:7326 > [ 0.839698] Modules linked in: > [ 0.839702] CPU: 0 PID: 46 Comm: vball...

...set_config are expected to fail. Cornelia, I think ccw and config_area should be allocated inside vcdev. You could either use pointers, or simply allocate vcdev with GDP_DMA. This would avoid the kmalloc inside these calls. Thanks, Rusty. > > [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at > [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 > [ 0.839694] ------------[ cut here ]------------ > [ 0.839697] WARNING: at kernel/sched/core.c:7326 > [ 0.839698] Modules linked in: > [ 0.839702] CPU: 0 PID: 46 Comm: vball...

On Thu, 26 Feb 2015 11:50:42 +1030 Rusty Russell <rusty at rustcorp.com.au> wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > Hi all, > > > > with the recent kernel 3.19, I get a kernel warning when I start my > > KVM guest on s390 with virtio balloon enabled: > > The deeper problem is that virtio_ccw_get_config just silently fails on

On Thu, 26 Feb 2015 11:50:42 +1030 Rusty Russell <rusty at rustcorp.com.au> wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > Hi all, > > > > with the recent kernel 3.19, I get a kernel warning when I start my > > KVM guest on s390 with virtio balloon enabled: > > The deeper problem is that virtio_ccw_get_config just silently fails on

...errupt. > > > > > > And it makes sense: config is not data path, I don't think > > > we should spin there. > > > > > > So I think besides these two parts, we still need my two patches: > > > virtio-balloon: do not call blocking ops when !TASK_RUNNING > > > > I prefer to annotate, over trying to fix this. > > > > Because it's not important. We might spin a few times, but it's very > > unlikely, and it's certainly not performance critical. > > > > Thanks, > > Rusty. > > &g...

...errupt. > > > > > > And it makes sense: config is not data path, I don't think > > > we should spin there. > > > > > > So I think besides these two parts, we still need my two patches: > > > virtio-balloon: do not call blocking ops when !TASK_RUNNING > > > > I prefer to annotate, over trying to fix this. > > > > Because it's not important. We might spin a few times, but it's very > > unlikely, and it's certainly not performance critical. > > > > Thanks, > > Rusty. > > &g...

...en without kmalloc, on s390 get_config is blocking - it's waiting for a hardware interrupt. And it makes sense: config is not data path, I don't think we should spin there. So I think besides these two parts, we still need my two patches: virtio-balloon: do not call blocking ops when !TASK_RUNNING virtio_console: avoid config access from irq in 4.0. agree?

...en without kmalloc, on s390 get_config is blocking - it's waiting for a hardware interrupt. And it makes sense: config is not data path, I don't think we should spin there. So I think besides these two parts, we still need my two patches: virtio-balloon: do not call blocking ops when !TASK_RUNNING virtio_console: avoid config access from irq in 4.0. agree?

On Wed, 25 Feb 2015 15:14:36 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >

On Wed, 25 Feb 2015 15:36:02 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >

On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > Hi all, > > > > with the recent kernel 3.19, I get a kernel warning when I start my > > KVM guest on s390 with virtio balloon enabled: > > The deeper problem is that virtio_ccw_get_config just silently fails on > OOM. Same problem with

Thomas Huth <thuth at linux.vnet.ibm.com> writes: > On Thu, 26 Feb 2015 11:50:42 +1030 > Rusty Russell <rusty at rustcorp.com.au> wrote: > >> Thomas Huth <thuth at linux.vnet.ibm.com> writes: >> > Hi all, >> > >> > with the recent kernel 3.19, I get a kernel warning when I start my >> > KVM guest on s390 with virtio balloon

On Mon, 2 Mar 2015 12:46:57 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Mar 02, 2015 at 12:31:06PM +0100, Cornelia Huck wrote: > > On Mon, 2 Mar 2015 12:13:58 +0100 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > On Mon, Mar 02, 2015 at 10:37:26AM +1030, Rusty Russell wrote: > > > > Thomas

On Wed, 25 Feb 2015 15:14:36 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >