mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Vincent Legout <vincent.legout@gandi.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device
Date: Tue, 4 Jul 2017 17:59:27 +0100	[thread overview]
Message-ID: <20170704165927.c6dgitftm4v3xk7w@dhcp-3-128.uk.xensource.com> (raw)
In-Reply-To: <20170704114823.pvk6323gfebioikl@bres.gandi.net>

On Tue, Jul 04, 2017 at 01:48:32PM +0200, Vincent Legout wrote:
> Devices are not unmounted inside a domU after a xl block-detach.
> 
> After xl block-detach, blkfront_closing() is called with state ==
> XenbusStateConnected, it detects that the device is still in use and
> only switches state to XenbusStateClosing. blkfront_closing() is called
> a second time but returns immediately because state ==
> XenbusStateClosing. Thus the device keeps being mounted inside the domU.
> 
> To fix this, emit a KOBJ_OFFLINE uevent even if the device has users.
> 
> With this patch, inside domU, udev has:
> 
> KERNEL[16994.526789] offline  /devices/vbd-51728/block/xvdb (block)
> KERNEL[16994.796197] remove   /devices/virtual/bdi/202:16 (bdi)
> KERNEL[16994.797167] remove   /devices/vbd-51728/block/xvdb (block)
> UDEV  [16994.798035] remove   /devices/virtual/bdi/202:16 (bdi)
> UDEV  [16994.809429] offline  /devices/vbd-51728/block/xvdb (block)
> UDEV  [16994.842365] remove   /devices/vbd-51728/block/xvdb (block)
> KERNEL[16995.461991] remove   /devices/vbd-51728 (xen)
> UDEV  [16995.462549] remove   /devices/vbd-51728 (xen)

I'm not an expect on udev, but aren't those messages duplicated? You
seem to get one message from udev and another one from the kernel.

> While without, it had:
> 
> KERNEL[30.862764] remove   /devices/vbd-51728 (xen)
> UDEV  [30.867838] remove   /devices/vbd-51728 (xen)
> 
> Signed-off-by: Pascal Bouchareine <pascal@gandi.net>
> Signed-off-by: Fatih Acar <fatih.acar@gandi.net>
> Signed-off-by: Vincent Legout <vincent.legout@gandi.net>
>
>  drivers/block/xen-blkfront.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 39459631667c..da0b0444ee1f 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2185,8 +2185,10 @@ static void blkfront_closing(struct blkfront_info *info)
>  	mutex_lock(&bdev->bd_mutex);
>  
>  	if (bdev->bd_openers) {
> -		xenbus_dev_error(xbdev, -EBUSY,
> -				 "Device in use; refusing to close");
> +		dev_warn(disk_to_dev(info->gd),
> +			 "detaching %s with pending users\n",
> +			 xbdev->nodename);
> +		kobject_uevent(&disk_to_dev(info->gd)->kobj, KOBJ_OFFLINE);

What happens if you simply remove the xenbus_dev_error but don't add
the kobject_uevent?

I'm asking because I don't see any other block device calling
directly kobject_uevent, and I'm sure this should be pretty similar to
what virtio or USB do when a block device is hot-unplugged.

For example blk_unregister_queue already contains a call to trigger a
kobject_uevent.

Thanks, Roger.

  reply	other threads:[~2017-07-04 16:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-04 11:48 Vincent Legout
2017-07-04 16:59 ` Roger Pau Monné [this message]
2017-07-05  8:08   ` Vincent Legout
2017-07-05  8:17     ` [Xen-devel] " Jan Beulich
2017-07-05 12:37       ` Vincent Legout
2017-07-05 12:53         ` Jan Beulich
2017-07-05 13:30           ` Vincent Legout
2017-07-07  8:10             ` Roger Pau Monné
2017-09-05  7:28               ` Vincent Legout
2017-09-06 10:18                 ` Juergen Gross
2017-09-06 14:57                   ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170704165927.c6dgitftm4v3xk7w@dhcp-3-128.uk.xensource.com \
    --to=roger.pau@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vincent.legout@gandi.net \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®