All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mark Wu <dwu@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Tejun Heo <tj@kernel.org>,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
Date: Wed, 19 Oct 2011 12:12:21 +0200	[thread overview]
Message-ID: <20111019101220.GE25794@redhat.com> (raw)
In-Reply-To: <4DF0A374.6090504@redhat.com>

On Thu, Jun 09, 2011 at 06:41:56AM -0400, Mark Wu wrote:
> On 06/09/2011 05:14 AM, Tejun Heo wrote:
> > Hello,
> > 
> > On Thu, Jun 09, 2011 at 08:51:05AM +0930, Rusty Russell wrote:
> >> On Wed, 08 Jun 2011 09:08:29 -0400, Mark Wu <dwu@redhat.com> wrote:
> >>> Hi Rusty,
> >>> Yes, I can't figure out an instance of disk probing in parallel either, but as
> >>> per the following commit, I think we still need use lock for safety. What's your opinion?
> >>>
> >>> commit 4034cc68157bfa0b6622efe368488d3d3e20f4e6
> >>> Author: Tejun Heo <tj@kernel.org>
> >>> Date:   Sat Feb 21 11:04:45 2009 +0900
> >>>
> >>>     [SCSI] sd: revive sd_index_lock
> >>>
> >>>     Commit f27bac2761cab5a2e212dea602d22457a9aa6943 which converted sd to
> >>>     use ida instead of idr incorrectly removed sd_index_lock around id
> >>>     allocation and free.  idr/ida do have internal locks but they protect
> >>>     their free object lists not the allocation itself.  The caller is
> >>>     responsible for that.  This missing synchronization led to the same id
> >>>     being assigned to multiple devices leading to oops.
> >>
> >> I'm confused.  Tejun, Greg, anyone can probes happen in parallel?
> >>
> >> If so, I'll have to review all my drivers.
> > 
> > Unless async is explicitly used, probe happens sequentially.  IOW, if
> > there's no async_schedule() call, things won't happen in parallel.
> > That said, I think it wouldn't be such a bad idea to protect ida with
> > spinlock regardless unless the probe code explicitly requires
> > serialization.
> > 
> > Thanks.
> > 
> Since virtio blk driver doesn't use async probe, it needn't use spinlock to protect ida.
> So remove the lock from patch.
> 
> >From fbb396df9dbf8023f1b268be01b43529a3993d57 Mon Sep 17 00:00:00 2001
> From: Mark Wu <dwu@redhat.com>
> Date: Thu, 9 Jun 2011 06:34:07 -0400
> Subject: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
> 
> Current index allocation in virtio-blk is based on a monotonically
> increasing variable "index". It could cause some confusion about disk
> name in the case of hot-plugging disks. And it's impossible to find the
> lowest available index by just maintaining a simple index. So it's
> changed to use ida to allocate index via referring to the index
> allocation in scsi disk.
> 
> Signed-off-by: Mark Wu <dwu@redhat.com>

Acked-by: Michael S. Tsirkin <mst@redhat.com>

This got lost in the noise and missed 3.1 which is unfortunate.
How about we apply this as is and look at cleanups as a next step?

> ---
>  drivers/block/virtio_blk.c |   28 +++++++++++++++++++++++-----
>  1 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 079c088..bf81ab6 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -8,10 +8,13 @@
>  #include <linux/scatterlist.h>
>  #include <linux/string_helpers.h>
>  #include <scsi/scsi_cmnd.h>
> +#include <linux/idr.h>
>  
>  #define PART_BITS 4
>  
> -static int major, index;
> +static int major;
> +static DEFINE_IDA(vd_index_ida);
> +
>  struct workqueue_struct *virtblk_wq;
>  
>  struct virtio_blk
> @@ -23,6 +26,7 @@ struct virtio_blk
>  
>  	/* The disk structure for the kernel. */
>  	struct gendisk *disk;
> +	u32 index;
>  
>  	/* Request tracking. */
>  	struct list_head reqs;
> @@ -343,12 +347,23 @@ static int __devinit virtblk_probe(struct virtio_device *vdev)
>  	struct request_queue *q;
>  	int err;
>  	u64 cap;
> -	u32 v, blk_size, sg_elems, opt_io_size;
> +	u32 v, blk_size, sg_elems, opt_io_size, index;
>  	u16 min_io_size;
>  	u8 physical_block_exp, alignment_offset;
>  
> -	if (index_to_minor(index) >= 1 << MINORBITS)
> -		return -ENOSPC;
> +	do {
> +		if (!ida_pre_get(&vd_index_ida, GFP_KERNEL))
> +			return -ENOMEM;
> +		err = ida_get_new(&vd_index_ida, &index);
> +	} while (err == -EAGAIN);
> +
> +	if (err)
> +		return err;
> +
> +	if (index_to_minor(index) >= 1 << MINORBITS) {
> +		err =  -ENOSPC;
> +		goto out_free_index;
> +	}
>  
>  	/* We need to know how many segments before we allocate. */
>  	err = virtio_config_val(vdev, VIRTIO_BLK_F_SEG_MAX,
> @@ -421,7 +436,7 @@ static int __devinit virtblk_probe(struct virtio_device *vdev)
>  	vblk->disk->private_data = vblk;
>  	vblk->disk->fops = &virtblk_fops;
>  	vblk->disk->driverfs_dev = &vdev->dev;
> -	index++;
> +	vblk->index = index;
>  
>  	/* configure queue flush support */
>  	if (virtio_has_feature(vdev, VIRTIO_BLK_F_FLUSH))
> @@ -516,6 +531,8 @@ out_free_vq:
>  	vdev->config->del_vqs(vdev);
>  out_free_vblk:
>  	kfree(vblk);
> +out_free_index:
> +	ida_remove(&vd_index_ida, index);
>  out:
>  	return err;
>  }
> @@ -538,6 +555,7 @@ static void __devexit virtblk_remove(struct virtio_device *vdev)
>  	mempool_destroy(vblk->pool);
>  	vdev->config->del_vqs(vdev);
>  	kfree(vblk);
> +	ida_remove(&vd_index_ida, vblk->index);
>  }
>  
>  static const struct virtio_device_id id_table[] = {
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2011-10-19 10:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01  7:24 [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index Mark Wu
2011-06-01  8:25 ` Mark Wu
2011-06-01  8:25 ` Mark Wu
2011-06-02 10:34   ` Michael S. Tsirkin
2011-06-02 10:34   ` Michael S. Tsirkin
2011-06-08 13:12     ` Mark Wu
2011-06-08 13:12     ` Mark Wu
2011-06-01 23:57 ` Rusty Russell
2011-06-08 13:08   ` Mark Wu
2011-06-08 13:08   ` Mark Wu
2011-06-08 23:21     ` Rusty Russell
2011-06-08 23:45       ` Greg KH
2011-06-08 23:45       ` Greg KH
2011-06-09  9:14       ` Tejun Heo
2011-06-09  9:14       ` Tejun Heo
2011-06-09 10:41         ` Mark Wu
2011-06-15  4:51           ` Rusty Russell
2011-06-15  4:51           ` Rusty Russell
2011-06-15  7:06             ` Tejun Heo
2011-06-16  0:05               ` Rusty Russell
2011-06-16  7:46                 ` Tejun Heo
2011-06-16  7:46                 ` Tejun Heo
2011-06-16  0:05               ` Rusty Russell
2011-06-15  7:06             ` Tejun Heo
2011-10-19 10:12           ` Michael S. Tsirkin [this message]
2011-10-24 10:02             ` Michael S. Tsirkin
2011-10-24 10:02               ` Jens Axboe
2011-10-25  1:07                 ` Rusty Russell
2011-06-09 10:41         ` Mark Wu
2011-06-08 23:21     ` Rusty Russell
2011-06-01 23:57 ` Rusty Russell
2011-06-02 10:33 ` Michael S. Tsirkin
2011-06-02 10:33 ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2011-06-01  7:24 Mark Wu

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=20111019101220.GE25794@redhat.com \
    --to=mst@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dwu@redhat.com \
    --cc=gregkh@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tj@kernel.org \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.