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

[Valentin Priescu <vali.priescu@gmail.com>]

Hi Konrad,

Do you have any comments regarding this patch?

--
Valentin

On Tue, May 20, 2014 at 10:28 PM, Valentin Priescu
<vali.priescu@gmail.com> wrote:
> From: Valentin Priescu <priescuv@amazon.com>
>
> 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@amazon.com>
> Reviewed-by: Steven Kady <stevkady@amazon.com>
> Reviewed-by: Steven Noonan <snoonan@amazon.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> ---
> v2: Reworked an 'if' statement in xen_blkif_disconnect(), as
>     suggested by David Vrabel <david.vrabel@citrix.com>
>     Handle the case when xen_blkif_disconnect() returns -EBUSY on
>     frontend_changed(), as noted by David Vrabel <david.vrabel@citrix.com>
> v3: Update reviewers list.
>