<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.kernel.virtualization">
    <title>gmane.linux.kernel.virtualization</title>
    <link>http://blog.gmane.org/gmane.linux.kernel.virtualization</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15510"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15509"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15508"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15507"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15506"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15505"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15504"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15503"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15502"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15501"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15500"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15499"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15498"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15497"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15496"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15495"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15494"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15493"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15492"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15491"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15510">
    <title>Re: [PATCH v2 3/3] virtio-blk: Use block layer provided spinlock</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15510</link>
    <description>&lt;pre&gt;
The above is fixed by your patch
block: Fix lock unbalance caused by lock disconnect
so it really seems beside the point here.
So I think the part of the commit log that
makes sense starts here?



Well why not.

Acked-by: Michael S. Tsirkin &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T13:10:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15509">
    <title>[PATCH v2 3/3] virtio-blk: Use block layer provided spinlock</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15509</link>
    <description>&lt;pre&gt;Block layer will allocate a spinlock for the queue if the driver does
not provide one in blk_init_queue().

The reason to use the internal spinlock is that blk_cleanup_queue() will
switch to use the internal spinlock in the cleanup code path.

        if (q-&amp;gt;queue_lock != &amp;amp;q-&amp;gt;__queue_lock)
                q-&amp;gt;queue_lock = &amp;amp;q-&amp;gt;__queue_lock;

However, processes which are in D state might have taken the driver
provided spinlock, when the processes wake up, they would release the
block provided spinlock.

=====================================
[ BUG: bad unlock balance detected! ]
3.4.0-rc7+ #238 Not tainted
-------------------------------------
fio/3587 is trying to release lock (&amp;amp;(&amp;amp;q-&amp;gt;__queue_lock)-&amp;gt;rlock) at:
[&amp;lt;ffffffff813274d2&amp;gt;] blk_queue_bio+0x2a2/0x380
but there are no more locks to release!

other info that might help us debug this:
1 lock held by fio/3587:
 #0:  (&amp;amp;(&amp;amp;vblk-&amp;gt;lock)-&amp;gt;rlock){......}, at:
[&amp;lt;ffffffff8132661a&amp;gt;] get_request_wait+0x19a/0x250

Other drivers use block layer provided spinlock as well, e.g. SCSI.

Switching to the block layer provided spinlock saves a bit of memory and
does not increase lock contention. Performance test shows no real
difference is observed before and after this patch.

Changes in v2: Improve commit log as Michael suggested.

Cc: Rusty Russell &amp;lt;rusty&amp;lt; at &amp;gt;rustcorp.com.au&amp;gt;
Cc: "Michael S. Tsirkin" &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;
Cc: virtualization&amp;lt; at &amp;gt;lists.linux-foundation.org
Cc: kvm&amp;lt; at &amp;gt;vger.kernel.org
Signed-off-by: Asias He &amp;lt;asias&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/block/virtio_blk.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index b4fa2d7..774c31d 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -21,8 +21,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct workqueue_struct *virtblk_wq;
 
 struct virtio_blk
 {
-spinlock_t lock;
-
 struct virtio_device *vdev;
 struct virtqueue *vq;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -65,7 +63,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void blk_done(struct virtqueue *vq)
 unsigned int len;
 unsigned long flags;
 
-spin_lock_irqsave(&amp;amp;vblk-&amp;gt;lock, flags);
+spin_lock_irqsave(vblk-&amp;gt;disk-&amp;gt;queue-&amp;gt;queue_lock, flags);
 while ((vbr = virtqueue_get_buf(vblk-&amp;gt;vq, &amp;amp;len)) != NULL) {
 int error;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -99,7 +97,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void blk_done(struct virtqueue *vq)
 }
 /* In case queue is stopped waiting for more buffers. */
 blk_start_queue(vblk-&amp;gt;disk-&amp;gt;queue);
-spin_unlock_irqrestore(&amp;amp;vblk-&amp;gt;lock, flags);
+spin_unlock_irqrestore(vblk-&amp;gt;disk-&amp;gt;queue-&amp;gt;queue_lock, flags);
 }
 
 static bool do_req(struct request_queue *q, struct virtio_blk *vblk,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -431,7 +429,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __devinit virtblk_probe(struct virtio_device *vdev)
 goto out_free_index;
 }
 
-spin_lock_init(&amp;amp;vblk-&amp;gt;lock);
 vblk-&amp;gt;vdev = vdev;
 vblk-&amp;gt;sg_elems = sg_elems;
 sg_init_table(vblk-&amp;gt;sg, vblk-&amp;gt;sg_elems);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -456,7 +453,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __devinit virtblk_probe(struct virtio_device *vdev)
 goto out_mempool;
 }
 
-q = vblk-&amp;gt;disk-&amp;gt;queue = blk_init_queue(do_virtblk_request, &amp;amp;vblk-&amp;gt;lock);
+q = vblk-&amp;gt;disk-&amp;gt;queue = blk_init_queue(do_virtblk_request, NULL);
 if (!q) {
 err = -ENOMEM;
 goto out_put_disk;
&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T08:03:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15508">
    <title>Re: [PATCH 3/3] virtio-blk: Use block layer provided spinlock</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15508</link>
    <description>&lt;pre&gt;
Hmm. Why using the internal lock will have impact on the performance? 
Anyway I will update the commit log.


yes ;-)


See the patch I sent this morning.

[PATCH] block: Fix lock unbalance caused by lock disconnect



Yes. I got your point. I am trying to fix block layer as well.


I think so.



&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T07:23:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15507">
    <title>Re: [PATCH 2/3] virtio-blk: Reset device after blk_cleanup_queue()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15507</link>
    <description>&lt;pre&gt;

Acked-by: Michael S. Tsirkin &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;


&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T07:08:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15506">
    <title>Re: [PATCH 1/3] virtio-blk: Call del_gendisk() before disable guestkick</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15506</link>
    <description>&lt;pre&gt;

Acked-by: Michael S. Tsirkin &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T07:07:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15505">
    <title>Re: [PATCH 2/3] virtio-blk: Reset device after blk_cleanup_queue()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15505</link>
    <description>&lt;pre&gt;
I see, thanks for the clarification.

&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T07:06:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15504">
    <title>Re: [PATCH 3/3] virtio-blk: Use block layer provided spinlock</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15504</link>
    <description>&lt;pre&gt;
OK, but the commit log is all wrong then, it should look like this:

virtio uses an internal lock while block layer provides
its own spinlock. Switching to the common lock saves
a bit of memory and does not seem to have any disadvantages:
this does not increase lock contention because .....
Performance tests show no real difference: before ... after ...



s/even/even if/ ?

The lock unblance issue wasn't yet discussed upstream, was it?

Looking at it from the other side, even if virtio can
work around the issue, block layer should be fixed if
it's buggy. Or maybe it's not buggy and this is just masking
some other real issue?

Does this mean it's inherently unsafe to use an internal spinlock?
Aren't there other drivers doing this?

&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T07:02:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15503">
    <title>Re: [PATCH 2/3] virtio-blk: Reset device after blk_cleanup_queue()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15503</link>
    <description>&lt;pre&gt;
No. This is not a problem. Actually, blk_cleanup_queue assumes the 
device can process the requests before queue DEAD marking. Otherwise the 
drain in the blk_cleanup_queue would never success.



&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T07:03:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15502">
    <title>Re: [PATCH 2/3] virtio-blk: Reset device after blk_cleanup_queue()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15502</link>
    <description>&lt;pre&gt;
Device is not reset here yet, so it will process
some requests in parallel with blk_cleanup_queue.
Is this a problem? Why not?


&lt;/pre&gt;</description>
    <dc:creator>Michael S. Tsirkin</dc:creator>
    <dc:date>2012-05-25T06:52:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15501">
    <title>[PATCH 3/3] virtio-blk: Use block layer provided spinlock</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15501</link>
    <description>&lt;pre&gt;Block layer will allocate a spinlock for the queue if the driver does
not provide one in blk_init_queue().

The reason to use the internal spinlock is that blk_cleanup_queue() will
switch to use the internal spinlock in the cleanup code path.
        if (q-&amp;gt;queue_lock != &amp;amp;q-&amp;gt;__queue_lock)
                q-&amp;gt;queue_lock = &amp;amp;q-&amp;gt;__queue_lock;

However, processes which are in D state might have taken the driver
provided spinlock, when the processes wake up , they would release the
block provided spinlock.

=====================================
[ BUG: bad unlock balance detected! ]
3.4.0-rc7+ #238 Not tainted
-------------------------------------
fio/3587 is trying to release lock (&amp;amp;(&amp;amp;q-&amp;gt;__queue_lock)-&amp;gt;rlock) at:
[&amp;lt;ffffffff813274d2&amp;gt;] blk_queue_bio+0x2a2/0x380
but there are no more locks to release!

other info that might help us debug this:
1 lock held by fio/3587:
 #0:  (&amp;amp;(&amp;amp;vblk-&amp;gt;lock)-&amp;gt;rlock){......}, at:
[&amp;lt;ffffffff8132661a&amp;gt;] get_request_wait+0x19a/0x250

Other drivers use block layer provided spinlock as well, e.g. SCSI.  I
do not see any reason why we shouldn't, even the lock unblance issue can
be fixed by block layer.

Cc: Rusty Russell &amp;lt;rusty&amp;lt; at &amp;gt;rustcorp.com.au&amp;gt;
Cc: "Michael S. Tsirkin" &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;
Cc: virtualization&amp;lt; at &amp;gt;lists.linux-foundation.org
Cc: kvm&amp;lt; at &amp;gt;vger.kernel.org
Signed-off-by: Asias He &amp;lt;asias&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/block/virtio_blk.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index b4fa2d7..774c31d 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -21,8 +21,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct workqueue_struct *virtblk_wq;
 
 struct virtio_blk
 {
-spinlock_t lock;
-
 struct virtio_device *vdev;
 struct virtqueue *vq;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -65,7 +63,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void blk_done(struct virtqueue *vq)
 unsigned int len;
 unsigned long flags;
 
-spin_lock_irqsave(&amp;amp;vblk-&amp;gt;lock, flags);
+spin_lock_irqsave(vblk-&amp;gt;disk-&amp;gt;queue-&amp;gt;queue_lock, flags);
 while ((vbr = virtqueue_get_buf(vblk-&amp;gt;vq, &amp;amp;len)) != NULL) {
 int error;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -99,7 +97,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void blk_done(struct virtqueue *vq)
 }
 /* In case queue is stopped waiting for more buffers. */
 blk_start_queue(vblk-&amp;gt;disk-&amp;gt;queue);
-spin_unlock_irqrestore(&amp;amp;vblk-&amp;gt;lock, flags);
+spin_unlock_irqrestore(vblk-&amp;gt;disk-&amp;gt;queue-&amp;gt;queue_lock, flags);
 }
 
 static bool do_req(struct request_queue *q, struct virtio_blk *vblk,
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -431,7 +429,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __devinit virtblk_probe(struct virtio_device *vdev)
 goto out_free_index;
 }
 
-spin_lock_init(&amp;amp;vblk-&amp;gt;lock);
 vblk-&amp;gt;vdev = vdev;
 vblk-&amp;gt;sg_elems = sg_elems;
 sg_init_table(vblk-&amp;gt;sg, vblk-&amp;gt;sg_elems);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -456,7 +453,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __devinit virtblk_probe(struct virtio_device *vdev)
 goto out_mempool;
 }
 
-q = vblk-&amp;gt;disk-&amp;gt;queue = blk_init_queue(do_virtblk_request, &amp;amp;vblk-&amp;gt;lock);
+q = vblk-&amp;gt;disk-&amp;gt;queue = blk_init_queue(do_virtblk_request, NULL);
 if (!q) {
 err = -ENOMEM;
 goto out_put_disk;
&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T02:34:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15500">
    <title>[PATCH 2/3] virtio-blk: Reset device after blk_cleanup_queue()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15500</link>
    <description>&lt;pre&gt;blk_cleanup_queue() will call blk_drian_queue() to drain all the
requests before queue DEAD marking. If we reset the device before
blk_cleanup_queue() the drain would fail.

1) if the queue is stopped in do_virtblk_request() because device is
full, the q-&amp;gt;request_fn() will not be called.

blk_drain_queue() {
   while(true) {
      ...
      if (!list_empty(&amp;amp;q-&amp;gt;queue_head))
        __blk_run_queue(q) {
    if (queue is not stoped)
q-&amp;gt;request_fn()
}
      ...
   }
}

Do no reset the device before blk_cleanup_queue() gives the chance to
start the queue in interrupt handler blk_done().

2) In commit b79d866c8b7014a51f611a64c40546109beaf24a, We abort requests
dispatched to driver before blk_cleanup_queue(). There is a race if
requests are dispatched to driver after the abort and before the queue
DEAD mark. To fix this, instead of aborting the requests explicitly, we
can just reset the device after after blk_cleanup_queue so that the
device can complete all the requests before queue DEAD marking in the
drain process.

Cc: Rusty Russell &amp;lt;rusty&amp;lt; at &amp;gt;rustcorp.com.au&amp;gt;
Cc: "Michael S. Tsirkin" &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;
Cc: virtualization&amp;lt; at &amp;gt;lists.linux-foundation.org
Cc: kvm&amp;lt; at &amp;gt;vger.kernel.org
Signed-off-by: Asias He &amp;lt;asias&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/block/virtio_blk.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 1bed517..b4fa2d7 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -576,8 +576,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void __devexit virtblk_remove(struct virtio_device *vdev)
 {
 struct virtio_blk *vblk = vdev-&amp;gt;priv;
 int index = vblk-&amp;gt;index;
-struct virtblk_req *vbr;
-unsigned long flags;
 
 /* Prevent config work handler from accessing the device. */
 mutex_lock(&amp;amp;vblk-&amp;gt;config_lock);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -585,21 +583,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void __devexit virtblk_remove(struct virtio_device *vdev)
 mutex_unlock(&amp;amp;vblk-&amp;gt;config_lock);
 
 del_gendisk(vblk-&amp;gt;disk);
+blk_cleanup_queue(vblk-&amp;gt;disk-&amp;gt;queue);
 
 /* Stop all the virtqueues. */
 vdev-&amp;gt;config-&amp;gt;reset(vdev);
 
 flush_work(&amp;amp;vblk-&amp;gt;config_work);
 
-/* Abort requests dispatched to driver. */
-spin_lock_irqsave(&amp;amp;vblk-&amp;gt;lock, flags);
-while ((vbr = virtqueue_detach_unused_buf(vblk-&amp;gt;vq))) {
-__blk_end_request_all(vbr-&amp;gt;req, -EIO);
-mempool_free(vbr, vblk-&amp;gt;pool);
-}
-spin_unlock_irqrestore(&amp;amp;vblk-&amp;gt;lock, flags);
-
-blk_cleanup_queue(vblk-&amp;gt;disk-&amp;gt;queue);
 put_disk(vblk-&amp;gt;disk);
 mempool_destroy(vblk-&amp;gt;pool);
 vdev-&amp;gt;config-&amp;gt;del_vqs(vdev);
&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T02:34:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15499">
    <title>[PATCH 1/3] virtio-blk: Call del_gendisk() before disable guest kick</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15499</link>
    <description>&lt;pre&gt;del_gendisk() might not return due to failing to remove the
/sys/block/vda/serial sysfs entry when another thread (udev) is
trying to read it.

virtblk_remove()
  vdev-&amp;gt;config-&amp;gt;reset() : guest will not kick us through interrupt
    del_gendisk()
      device_del()
        kobject_del(): got stuck, sysfs entry ref count non zero

sysfs_open_file(): user space process read /sys/block/vda/serial
   sysfs_get_active() : got sysfs entry ref count
      dev_attr_show()
        virtblk_serial_show()
           blk_execute_rq() : got stuck, interrupt is disabled
                              request cannot be finished

This patch fixes it by calling del_gendisk() before we disable guest's
interrupt so that the request sent in virtblk_serial_show() will be
finished and del_gendisk() will success.

This fixes another race in hot-unplug process.

It is save to call del_gendisk(vblk-&amp;gt;disk) before
flush_work(&amp;amp;vblk-&amp;gt;config_work) which might access vblk-&amp;gt;disk, because
vblk-&amp;gt;disk is not freed until put_disk(vblk-&amp;gt;disk).

Cc: Rusty Russell &amp;lt;rusty&amp;lt; at &amp;gt;rustcorp.com.au&amp;gt;
Cc: "Michael S. Tsirkin" &amp;lt;mst&amp;lt; at &amp;gt;redhat.com&amp;gt;
Cc: virtualization&amp;lt; at &amp;gt;lists.linux-foundation.org
Cc: kvm&amp;lt; at &amp;gt;vger.kernel.org
Signed-off-by: Asias He &amp;lt;asias&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/block/virtio_blk.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 693187d..1bed517 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -584,13 +584,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void __devexit virtblk_remove(struct virtio_device *vdev)
 vblk-&amp;gt;config_enable = false;
 mutex_unlock(&amp;amp;vblk-&amp;gt;config_lock);
 
+del_gendisk(vblk-&amp;gt;disk);
+
 /* Stop all the virtqueues. */
 vdev-&amp;gt;config-&amp;gt;reset(vdev);
 
 flush_work(&amp;amp;vblk-&amp;gt;config_work);
 
-del_gendisk(vblk-&amp;gt;disk);
-
 /* Abort requests dispatched to driver. */
 spin_lock_irqsave(&amp;amp;vblk-&amp;gt;lock, flags);
 while ((vbr = virtqueue_detach_unused_buf(vblk-&amp;gt;vq))) {
&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T02:34:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15498">
    <title>[PATCH 0/3] Fix hot-unplug race in virtio-blk</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15498</link>
    <description>&lt;pre&gt;This patch set fixes the race when hot-unplug stressed disk.

Asias He (3):
  virtio-blk: Call del_gendisk() before disable guest kick
  virtio-blk: Reset device after blk_cleanup_queue()
  virtio-blk: Use block layer provided spinlock

 drivers/block/virtio_blk.c |   25 ++++++-------------------
 1 file changed, 6 insertions(+), 19 deletions(-)

&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-25T02:34:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15497">
    <title>Re: [RFC PATCH 1/5] block: Introduce q-&gt;abort_queue_fn()</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15497</link>
    <description>&lt;pre&gt;


Well. I think I can do the cleanup in virtio driver without introducing 
a new API now. We can reset the device after blk_cleanup_queue so that 
the device can complete all the requests before queue DEAD marking. This 
would be much simpler.

Thanks for pointing out, Tejun ;-)

&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2012-05-23T15:04:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15496">
    <title>Re: [PATCH RESENT] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15496</link>
    <description>&lt;pre&gt;From: Marek Marczykowski &amp;lt;marmarek&amp;lt; at &amp;gt;invisiblethingslab.com&amp;gt;
Date: Sun, 20 May 2012 13:45:10 +0200


Applied, thanks.
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2012-05-22T20:50:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15495">
    <title>[PATCH RESENT] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15495</link>
    <description>&lt;pre&gt;Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.

Signed-off-by: Marek Marczykowski &amp;lt;marmarek&amp;lt; at &amp;gt;invisiblethingslab.com&amp;gt;
Acked-by: Ian Campbell &amp;lt;ian.campbell&amp;lt; at &amp;gt;citrix.com&amp;gt;
Acked-by: Konrad Rzeszutek Wilk &amp;lt;konrad.wilk&amp;lt; at &amp;gt;oracle.com&amp;gt;
---
 drivers/net/xen-netfront.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0ebbb19..2027afe 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1962,9 +1962,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __init netif_init(void)
 if (!xen_domain())
 return -ENODEV;
 
-if (xen_initial_domain())
-return 0;
-
 if (xen_hvm_domain() &amp;amp;&amp;amp; !xen_platform_pci_unplug)
 return -ENODEV;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1977,9 +1974,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; module_init(netif_init);
 
 static void __exit netif_exit(void)
 {
-if (xen_initial_domain())
-return;
-
 xenbus_unregister_driver(&amp;amp;netfront_driver);
 }
 module_exit(netif_exit);
&lt;/pre&gt;</description>
    <dc:creator>Marek Marczykowski</dc:creator>
    <dc:date>2012-05-20T11:45:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15494">
    <title>Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15494</link>
    <description>&lt;pre&gt;
Oh no! Marek, can you repin it please (along with all the Ack's on it).
&lt;/pre&gt;</description>
    <dc:creator>Konrad Rzeszutek Wilk</dc:creator>
    <dc:date>2012-05-22T19:43:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15493">
    <title>Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15493</link>
    <description>&lt;pre&gt;From: Ian Campbell &amp;lt;Ian.Campbell&amp;lt; at &amp;gt;citrix.com&amp;gt;
Date: Tue, 22 May 2012 20:30:28 +0100


Ok, but this patch doesn't appply cleanly at all to Linus's
current tree nor my 'net' tree (which are equal right now).
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2012-05-22T19:38:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15492">
    <title>Re: [Xen-devel] [PATCH] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15492</link>
    <description>&lt;pre&gt;
Konrad is "Xen folks" and has acked it already but FWIW:

Acked-by: Ian Campbell &amp;lt;ian.campbell&amp;lt; at &amp;gt;citrix.com&amp;gt;

Ian.

&lt;/pre&gt;</description>
    <dc:creator>Ian Campbell</dc:creator>
    <dc:date>2012-05-22T19:30:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15491">
    <title>Re: [PATCH] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15491</link>
    <description>&lt;pre&gt;From: Marek Marczykowski &amp;lt;marmarek&amp;lt; at &amp;gt;invisiblethingslab.com&amp;gt;
Date: Sun, 20 May 2012 13:45:10 +0200


Someone please review this and I can merge it in via the 'net' tree if
it looks OK to XEN folks.
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2012-05-22T19:13:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.virtualization/15490">
    <title>Re: [PATCH] xen: do not disable netfront in dom0</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.virtualization/15490</link>
    <description>&lt;pre&gt;
Acked-by: Konrad Rzeszutek Wilk &amp;lt;konrad.wilk&amp;lt; at &amp;gt;oracle.com&amp;gt;


&lt;/pre&gt;</description>
    <dc:creator>Konrad Rzeszutek Wilk</dc:creator>
    <dc:date>2012-05-22T18:34:33</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.kernel.virtualization">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.kernel.virtualization</link>
  </textinput>
</rdf:RDF>

