Re: [Xen-devel] [PATCH v3] xen-blkback: defer freeing blkif to avoid blocking xenwatch

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Jun 02, 2014 at 06:13:22PM +0200, Valentin Priescu wrote:
> Hi Konrad,
> 
> Do you have any comments regarding this patch?

No. Patch had been already pulled by Jens for 3.16.
> 
> --
> Valentin
> 
> On Tue, May 20, 2014 at 10:28 PM, Valentin Priescu
> <vali.priescu@xxxxxxxxx> wrote:
> > From: Valentin Priescu <priescuv@xxxxxxxxxx>
> >
> > Currently xenwatch blocks in VBD disconnect, waiting for all pending I/O
> > requests to finish. If the VBD is attached to a hot-swappable disk, then
> > xenwatch can hang for a long period of time, stalling other watches.
> >
> >  INFO: task xenwatch:39 blocked for more than 120 seconds.
> >  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >  ffff880057f01bd0 0000000000000246 ffff880057f01ac0 ffffffff810b0782
> >  ffff880057f01ad0 00000000000131c0 0000000000000004 ffff880057edb040
> >  ffff8800344c6080 0000000000000000 ffff880058c00ba0 ffff880057edb040
> >  Call Trace:
> >  [<ffffffff810b0782>] ? irq_to_desc+0x12/0x20
> >  [<ffffffff8128f761>] ? list_del+0x11/0x40
> >  [<ffffffff8147a080>] ? wait_for_common+0x60/0x160
> >  [<ffffffff8147bcef>] ? _raw_spin_lock_irqsave+0x2f/0x50
> >  [<ffffffff8147bd49>] ? _raw_spin_unlock_irqrestore+0x19/0x20
> >  [<ffffffff8147a26a>] schedule+0x3a/0x60
> >  [<ffffffffa018fe6a>] xen_blkif_disconnect+0x8a/0x100 [xen_blkback]
> >  [<ffffffff81079f70>] ? wake_up_bit+0x40/0x40
> >  [<ffffffffa018ffce>] xen_blkbk_remove+0xae/0x1e0 [xen_blkback]
> >  [<ffffffff8130b254>] xenbus_dev_remove+0x44/0x90
> >  [<ffffffff81345cb7>] __device_release_driver+0x77/0xd0
> >  [<ffffffff81346488>] device_release_driver+0x28/0x40
> >  [<ffffffff813456e8>] bus_remove_device+0x78/0xe0
> >  [<ffffffff81342c9f>] device_del+0x12f/0x1a0
> >  [<ffffffff81342d2d>] device_unregister+0x1d/0x60
> >  [<ffffffffa0190826>] frontend_changed+0xa6/0x4d0 [xen_blkback]
> >  [<ffffffffa019c252>] ? frontend_changed+0x192/0x650 [xen_netback]
> >  [<ffffffff8130ae50>] ? cmp_dev+0x60/0x60
> >  [<ffffffff81344fe4>] ? bus_for_each_dev+0x94/0xa0
> >  [<ffffffff8130b06e>] xenbus_otherend_changed+0xbe/0x120
> >  [<ffffffff8130b4cb>] frontend_changed+0xb/0x10
> >  [<ffffffff81309c82>] xenwatch_thread+0xf2/0x130
> >  [<ffffffff81079f70>] ? wake_up_bit+0x40/0x40
> >  [<ffffffff81309b90>] ? xenbus_directory+0x80/0x80
> >  [<ffffffff810799d6>] kthread+0x96/0xa0
> >  [<ffffffff81485934>] kernel_thread_helper+0x4/0x10
> >  [<ffffffff814839f3>] ? int_ret_from_sys_call+0x7/0x1b
> >  [<ffffffff8147c17c>] ? retint_restore_args+0x5/0x6
> >  [<ffffffff81485930>] ? gs_change+0x13/0x13
> >
> > With this patch, when there is still pending I/O, the actual disconnect
> > is done by the last reference holder (last pending I/O request). In this
> > case, xenwatch doesn't block indefinitely.
> >
> > Signed-off-by: Valentin Priescu <priescuv@xxxxxxxxxx>
> > Reviewed-by: Steven Kady <stevkady@xxxxxxxxxx>
> > Reviewed-by: Steven Noonan <snoonan@xxxxxxxxxx>
> > Reviewed-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> > ---
> > v2: Reworked an 'if' statement in xen_blkif_disconnect(), as
> >     suggested by David Vrabel <david.vrabel@xxxxxxxxxx>
> >     Handle the case when xen_blkif_disconnect() returns -EBUSY on
> >     frontend_changed(), as noted by David Vrabel <david.vrabel@xxxxxxxxxx>
> > v3: Update reviewers list.
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel