<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/block, branch v3.5.7</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>aoe: assert AoE packets marked as requiring no checksum</title>
<updated>2012-10-12T20:47:05+00:00</updated>
<author>
<name>Ed Cashin</name>
<email>ecashin@coraid.com</email>
</author>
<published>2012-09-19T15:46:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=67bc901299695962dff99263008ca25d1d24eb7e'/>
<id>67bc901299695962dff99263008ca25d1d24eb7e</id>
<content type='text'>
[ Upstream commit 8babe8cc6570ed896b7b596337eb8fe730c3ff45 ]

In order for the network layer to see that AoE requires
no checksumming in a generic way, the packets must be
marked as requiring no checksum, so we make this requirement
explicit with the assertion.

Signed-off-by: Ed Cashin &lt;ecashin@coraid.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8babe8cc6570ed896b7b596337eb8fe730c3ff45 ]

In order for the network layer to see that AoE requires
no checksumming in a generic way, the packets must be
marked as requiring no checksum, so we make this requirement
explicit with the assertion.

Signed-off-by: Ed Cashin &lt;ecashin@coraid.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/m2p: do not reuse kmap_op-&gt;dev_bus_addr</title>
<updated>2012-10-02T17:39:12+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@eu.citrix.com</email>
</author>
<published>2012-09-12T11:44:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=927766ff00c2f45847b77c9732c2e130313e0d0e'/>
<id>927766ff00c2f45847b77c9732c2e130313e0d0e</id>
<content type='text'>
commit 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 upstream.

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op-&gt;dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page-&gt;index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Reported-and-Tested-By: Sander Eikelenboom &lt;linux@eikelenboom.it&gt;
Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 upstream.

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op-&gt;dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page-&gt;index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Reported-and-Tested-By: Sander Eikelenboom &lt;linux@eikelenboom.it&gt;
Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nbd: clear waiting_queue on shutdown</title>
<updated>2012-10-02T17:39:11+00:00</updated>
<author>
<name>Paul Clements</name>
<email>paul.clements@steeleye.com</email>
</author>
<published>2012-09-17T21:09:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ea11e00964349c413950b0fe0d45422f92a9dd49'/>
<id>ea11e00964349c413950b0fe0d45422f92a9dd49</id>
<content type='text'>
commit fded4e090c60100d709318896c79816d68d5b47d upstream.

Fix a serious but uncommon bug in nbd which occurs when there is heavy
I/O going to the nbd device while, at the same time, a failure (server,
network) or manual disconnect of the nbd connection occurs.

There is a small window between the time that the nbd_thread is stopped
and the socket is shutdown where requests can continue to be queued to
nbd's internal waiting_queue.  When this happens, those requests are
never completed or freed.

The fix is to clear the waiting_queue on shutdown of the nbd device, in
the same way that the nbd request queue (queue_head) is already being
cleared.

Signed-off-by: Paul Clements &lt;paul.clements@steeleye.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fded4e090c60100d709318896c79816d68d5b47d upstream.

Fix a serious but uncommon bug in nbd which occurs when there is heavy
I/O going to the nbd device while, at the same time, a failure (server,
network) or manual disconnect of the nbd connection occurs.

There is a small window between the time that the nbd_thread is stopped
and the socket is shutdown where requests can continue to be queued to
nbd's internal waiting_queue.  When this happens, those requests are
never completed or freed.

The fix is to clear the waiting_queue on shutdown of the nbd device, in
the same way that the nbd request queue (queue_head) is already being
cleared.

Signed-off-by: Paul Clements &lt;paul.clements@steeleye.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cciss: fix handling of protocol error</title>
<updated>2012-10-02T17:38:57+00:00</updated>
<author>
<name>Stephen M. Cameron</name>
<email>scameron@beardog.cce.hp.com</email>
</author>
<published>2012-09-14T21:35:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=739b195387af0cea560925daa550b3ebca923642'/>
<id>739b195387af0cea560925daa550b3ebca923642</id>
<content type='text'>
commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream.

If a command completes with a status of CMD_PROTOCOL_ERR, this
information should be conveyed to the SCSI mid layer, not dropped
on the floor.  Unlike a similar bug in the hpsa driver, this bug
only affects tape drives and CD and DVD ROM drives in the cciss
driver, and to induce it, you have to disconnect (or damage) a
cable, so it is not a very likely scenario (which would explain
why the bug has gone undetected for the last 10 years.)

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream.

If a command completes with a status of CMD_PROTOCOL_ERR, this
information should be conveyed to the SCSI mid layer, not dropped
on the floor.  Unlike a similar bug in the hpsa driver, this bug
only affects tape drives and CD and DVD ROM drives in the cciss
driver, and to induce it, you have to disconnect (or damage) a
cable, so it is not a very likely scenario (which would explain
why the bug has gone undetected for the last 10 years.)

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cciss: fix incorrect scsi status reporting</title>
<updated>2012-09-14T16:59:36+00:00</updated>
<author>
<name>Stephen M. Cameron</name>
<email>scameron@beardog.cce.hp.com</email>
</author>
<published>2012-08-21T23:15:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9a132964d51bede2b6ac9df786ba92fb80fc9b97'/>
<id>9a132964d51bede2b6ac9df786ba92fb80fc9b97</id>
<content type='text'>
commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.

Delete code which sets SCSI status incorrectly as it's already been set
correctly above this incorrect code.  The bug was introduced in 2009 by
commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
lost.")

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Reported-by: Roel van Meer &lt;roel.vanmeer@bokxing.nl&gt;
Tested-by: Roel van Meer &lt;roel.vanmeer@bokxing.nl&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.

Delete code which sets SCSI status incorrectly as it's already been set
correctly above this incorrect code.  The bug was introduced in 2009 by
commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
lost.")

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Reported-by: Roel van Meer &lt;roel.vanmeer@bokxing.nl&gt;
Tested-by: Roel van Meer &lt;roel.vanmeer@bokxing.nl&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio-blk: Use block layer provided spinlock</title>
<updated>2012-08-15T14:52:30+00:00</updated>
<author>
<name>Asias He</name>
<email>asias@redhat.com</email>
</author>
<published>2012-05-25T08:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8058567e89b6f80b754f3edf5324b36f4b199849'/>
<id>8058567e89b6f80b754f3edf5324b36f4b199849</id>
<content type='text'>
commit 2c95a3290919541b846bee3e0fbaa75860929f53 upstream.

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-&gt;queue_lock != &amp;q-&gt;__queue_lock)
                q-&gt;queue_lock = &amp;q-&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;q-&gt;__queue_lock)-&gt;rlock) at:
[&lt;ffffffff813274d2&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;vblk-&gt;lock)-&gt;rlock){......}, at:
[&lt;ffffffff8132661a&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.

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2c95a3290919541b846bee3e0fbaa75860929f53 upstream.

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-&gt;queue_lock != &amp;q-&gt;__queue_lock)
                q-&gt;queue_lock = &amp;q-&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;q-&gt;__queue_lock)-&gt;rlock) at:
[&lt;ffffffff813274d2&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;vblk-&gt;lock)-&gt;rlock){......}, at:
[&lt;ffffffff8132661a&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.

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio-blk: Reset device after blk_cleanup_queue()</title>
<updated>2012-08-15T14:52:30+00:00</updated>
<author>
<name>Asias He</name>
<email>asias@redhat.com</email>
</author>
<published>2012-05-25T02:34:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c92867fad388d59e325ab439c8c560a3f8dff7ad'/>
<id>c92867fad388d59e325ab439c8c560a3f8dff7ad</id>
<content type='text'>
commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream.

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-&gt;request_fn() will not be called.

blk_drain_queue() {
   while(true) {
      ...
      if (!list_empty(&amp;q-&gt;queue_head))
        __blk_run_queue(q) {
	    if (queue is not stoped)
		q-&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.

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream.

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-&gt;request_fn() will not be called.

blk_drain_queue() {
   while(true) {
      ...
      if (!list_empty(&amp;q-&gt;queue_head))
        __blk_run_queue(q) {
	    if (queue is not stoped)
		q-&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.

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio-blk: Call del_gendisk() before disable guest kick</title>
<updated>2012-08-15T14:52:30+00:00</updated>
<author>
<name>Asias He</name>
<email>asias@redhat.com</email>
</author>
<published>2012-05-25T02:34:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9097a6af42d1f0d13908fda5c8933266fd49ae16'/>
<id>9097a6af42d1f0d13908fda5c8933266fd49ae16</id>
<content type='text'>
commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream.

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-&gt;config-&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-&gt;disk) before
flush_work(&amp;vblk-&gt;config_work) which might access vblk-&gt;disk, because
vblk-&gt;disk is not freed until put_disk(vblk-&gt;disk).

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream.

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-&gt;config-&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-&gt;disk) before
flush_work(&amp;vblk-&gt;config_work) which might access vblk-&gt;disk, because
vblk-&gt;disk is not freed until put_disk(vblk-&gt;disk).

Signed-off-by: Asias He &lt;asias@redhat.com&gt;
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rbd: endian bug in rbd_req_cb()</title>
<updated>2012-07-18T04:30:31+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2012-06-06T14:15:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6a3ca4f18873f950895cb64ddefafb51a732e3f7'/>
<id>6a3ca4f18873f950895cb64ddefafb51a732e3f7</id>
<content type='text'>
Sparse complains about this because:
drivers/block/rbd.c:996:20: warning: cast to restricted __le32
drivers/block/rbd.c:996:20: warning: cast from restricted __le16

These are set in osd_req_encode_op() and they are le16.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Alex Elder &lt;elder@inktank.com&gt;
(cherry picked from commit 895cfcc810e53d7d36639969c71efb9087221167)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sparse complains about this because:
drivers/block/rbd.c:996:20: warning: cast to restricted __le32
drivers/block/rbd.c:996:20: warning: cast from restricted __le16

These are set in osd_req_encode_op() and they are le16.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Alex Elder &lt;elder@inktank.com&gt;
(cherry picked from commit 895cfcc810e53d7d36639969c71efb9087221167)
</pre>
</div>
</content>
</entry>
<entry>
<title>rbd: Fix ceph_snap_context size calculation</title>
<updated>2012-07-18T04:30:19+00:00</updated>
<author>
<name>Yan, Zheng</name>
<email>zheng.z.yan@intel.com</email>
</author>
<published>2012-06-06T14:15:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=236df3755d944c33120d77e84b5ff6f3917eb307'/>
<id>236df3755d944c33120d77e84b5ff6f3917eb307</id>
<content type='text'>
ceph_snap_context-&gt;snaps is an u64 array

Signed-off-by: Zheng Yan &lt;zheng.z.yan@intel.com&gt;
Reviewed-by: Alex Elder &lt;elder@inktank.com&gt;
(cherry picked from commit f9f9a1904467816452fc70740165030e84c2c659)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ceph_snap_context-&gt;snaps is an u64 array

Signed-off-by: Zheng Yan &lt;zheng.z.yan@intel.com&gt;
Reviewed-by: Alex Elder &lt;elder@inktank.com&gt;
(cherry picked from commit f9f9a1904467816452fc70740165030e84c2c659)
</pre>
</div>
</content>
</entry>
</feed>
