linux.git/drivers/block, branch v4.13

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

2017-09-01T01:42:21+00:00

Pull block fixes from Jens Axboe:
 "Unfortunately a few issues that warrant sending another pull request,
  even if I had hoped to avoid it. This contains:

   - A fix for multiqueue xen-blkback, on tear down / disconnect.

   - A few fixups for NVMe, including a wrong bit definition, fix for
     host memory buffers, and an nvme rdma page size fix"

* 'for-linus' of git://git.kernel.dk/linux-block:
  nvme: fix the definition of the doorbell buffer config support bit
  nvme-pci: use dma memory for the host memory buffer descriptors
  nvme-rdma: default MR page size to 4k
  xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

Merge branch 'stable/for-jens-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus

2017-08-29T14:32:58+00:00

Pull xen-blkback fix from Konrad:

"[...] A bug-fix when shutting down xen block backend driver with
 multiple queues and the driver not clearing all of them."

Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost

2017-08-26T00:40:03+00:00

Pull virtio fixes from Michael Tsirkin:
 "Fixes two obvious bugs in virtio pci"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio_pci: fix cpu affinity support
  virtio_blk: fix incorrect message when disk is resized

xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

2017-08-25T19:59:34+00:00

In xen_blkif_disconnect, before checking inflight I/O, following code
stops the blkback thread,
if (ring->xenblkd) {
	kthread_stop(ring->xenblkd);
	wake_up(&ring->shutdown_wq);
}
If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and above code would not be called to stop thread of remaining
queue and processs them. When removing vbd device with lots of disk I/O
load, some queues with inflight I/O still have blkback thread running even
though the corresponding vbd device or guest is gone.
And this could cause some problems, for example, if the backend device type
is file, some loop devices and blkback thread always lingers there forever
after guest is destroyed, and this causes failure of umounting repositories
unless rebooting the dom0.
This patch allows thread of every queue has the chance to get stopped.
Otherwise, only thread of queue previous to(including) first busy one get
stopped, blkthread of remaining queue will still run.  So stop all threads
properly and return -EBUSY if any queue has inflight I/O.

Signed-off-by: Annie Li 
Reviewed-by: Herbert van den Bergh 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Adnan Misherfi 
Acked-by: Roger Pau Monné 
Signed-off-by: Konrad Rzeszutek Wilk

virtio_blk: fix incorrect message when disk is resized

2017-08-25T18:37:15+00:00

The message printed on disk resize is incorrect.  The following is
printed when resizing to 2 GiB:

  $ truncate -s 1G test.img
  $ qemu -device virtio-blk-pci,logical_block_size=4096,...
  (qemu) block_resize drive1 2G

  virtio_blk virtio0: new size: 4194304 4096-byte logical blocks (17.2 GB/16.0 GiB)

The virtio_blk capacity config field is in 512-byte sector units
regardless of logical_block_size as per the VIRTIO specification.
Therefore the message should read:

  virtio_blk virtio0: new size: 524288 4096-byte logical blocks (2.15 GB/2.0 GiB)

Note that this only affects the printed message.  Thankfully the actual
block device has the correct size because the block layer expects
capacity in sectors.

Signed-off-by: Stefan Hajnoczi 
Signed-off-by: Michael S. Tsirkin

Revert "loop: support 4k physical blocksize"

2017-08-23T21:57:55+00:00

There's some stuff still up in the air, let's not get stuck with a
subpar ABI. I'll follow up with something better for 4.14.

Signed-off-by: Omar Sandoval 
Signed-off-by: Jens Axboe

Merge branch 'stable/for-jens-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus

2017-08-16T15:56:34+00:00

Pull xen block changes from Konrad:

Two fixes, both of them spotted by Amazon:

 1) Fix in Xen-blkfront caused by the re-write in 4.8 time-frame.
 2) Fix in the xen_biovec_phys_mergeable which allowed guest
    requests when using NVMe - to slurp up more data than allowed
    leading to an XSA (which has been made public today).

xen-blkfront: use a right index when checking requests

2017-08-15T14:34:04+00:00

Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
has been using an index for iterating ring_info to check request when
iterating blk_shadow in an inner loop. This seems to have been
accidentally introduced during the massive rewrite of the block layer
macros in the commits.

This may cause crash like this:

[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
[11798.058832] IP: [] blkfront_resume+0x10a/0x610
....
[11798.061063] Call Trace:
[11798.061063]  [] xenbus_dev_resume+0x53/0x140
[11798.061063]  [] ? xenbus_dev_probe+0x150/0x150
[11798.061063]  [] dpm_run_callback+0x3e/0x110
[11798.061063]  [] device_resume+0x88/0x190
[11798.061063]  [] dpm_resume+0x100/0x2d0
[11798.061063]  [] dpm_resume_end+0x11/0x20
[11798.061063]  [] do_suspend+0xe8/0x1a0
[11798.061063]  [] shutdown_handler+0xfd/0x130
[11798.061063]  [] ? split+0x110/0x110
[11798.061063]  [] xenwatch_thread+0x86/0x120
[11798.061063]  [] ? prepare_to_wait_event+0x110/0x110
[11798.061063]  [] kthread+0xd7/0xf0
[11798.061063]  [] ? kfree+0x121/0x170
[11798.061063]  [] ? kthread_park+0x60/0x60
[11798.061063]  [] ?  call_usermodehelper_exec_work+0xb0/0xb0
[11798.061063]  [] ?  call_usermodehelper_exec_async+0x13a/0x140
[11798.061063]  [] ret_from_fork+0x25/0x30

Use the right index in the inner loop.

Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of git://git.kernel.dk/linux-block")
Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block")
Signed-off-by: Munehisa Kamata 
Reviewed-by: Thomas Friebel 
Reviewed-by: Eduardo Valentin 
Reviewed-by: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Reviewed-by: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org
Cc: stable@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk

zram: rework copy of compressor name in comp_algorithm_store()

2017-08-10T22:54:07+00:00

comp_algorithm_store() passes the size of the source buffer to strlcpy()
instead of the destination buffer size.  Make it explicit that the two
buffers have the same size and use strcpy() instead of strlcpy().  The
latter can be done safely since the function ensures that the string in
the source buffer is terminated.

Link: http://lkml.kernel.org/r/20170803163350.45245-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke 
Reviewed-by: Douglas Anderson 
Reviewed-by: Sergey Senozhatsky 
Acked-by: Minchan Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sunvdc: prevent sunvdc panic when mpgroup disk added to guest domain

2017-08-10T05:22:32+00:00

Using mpgroup to define multiple paths for a virtual disk causes multiple
virtual-device-port ports to be created for that virtual device.
Each virtual-device-port port then gets a vdisk created for it by the Linux
sunvdc driver. As mpgroup is not supported by the Linux sunvdc driver it
cannot handle multiple ports for a single vdisk, leading to a kernel panic
at startup.

This fix prevents more than one vdisk per virtual-device-port being created
until full virtual disk multipathing (mpgroup) support is implemented.

Signed-off-by: Jim Quigley 
Reviewed-by: Liam Merwick 
Reviewed-by: Shannon Nelson 
Reviewed-by: Alexandre Chartre 
Reviewed-by: Aaron Young 
Signed-off-by: David S. Miller