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

skd: Submit requests to firmware before triggering the doorbell

2017-09-27T12:39:21+00:00

commit 5fbd545cd3fd311ea1d6e8be4cedddd0ee5684c7 upstream.

Ensure that the members of struct skd_msg_buf have been transferred
to the PCIe adapter before the doorbell is triggered. This patch
avoids that I/O fails sporadically and that the following error
message is reported:

(skd0:STM000196603:[0000:00:09.0]): Completion mismatch comp_id=0x0000 skreq=0x0400 new=0x0000

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

skd: Avoid that module unloading triggers a use-after-free

2017-09-27T12:39:21+00:00

commit 7277cc67b3916eed47558c64f9c9c0de00a35cda upstream.

Since put_disk() triggers a disk_release() call and since that
last function calls blk_put_queue() if disk->queue != NULL, clear
the disk->queue pointer before calling put_disk(). This avoids
that unloading the skd kernel module triggers the following
use-after-free:

WARNING: CPU: 8 PID: 297 at lib/refcount.c:128 refcount_sub_and_test+0x70/0x80
refcount_t: underflow; use-after-free.
CPU: 8 PID: 297 Comm: kworker/8:1 Not tainted 4.11.10-300.fc26.x86_64 #1
Workqueue: events work_for_cpu_fn
Call Trace:
 dump_stack+0x63/0x84
 __warn+0xcb/0xf0
 warn_slowpath_fmt+0x5a/0x80
 refcount_sub_and_test+0x70/0x80
 refcount_dec_and_test+0x11/0x20
 kobject_put+0x1f/0x50
 blk_put_queue+0x15/0x20
 disk_release+0xae/0xf0
 device_release+0x32/0x90
 kobject_release+0x67/0x170
 kobject_put+0x2b/0x50
 put_disk+0x17/0x20
 skd_destruct+0x5c/0x890 [skd]
 skd_pci_probe+0x124d/0x13a0 [skd]
 local_pci_probe+0x42/0xa0
 work_for_cpu_fn+0x14/0x20
 process_one_work+0x19e/0x470
 worker_thread+0x1dc/0x4a0
 kthread+0x125/0x140
 ret_from_fork+0x25/0x30

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

xen-blkfront: use a right index when checking requests

2017-08-25T00:12:20+00:00

commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.

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
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

virtio_blk: fix panic in initialization error path

2017-08-11T15:49:36+00:00

[ Upstream commit 6bf6b0aa3da84a3d9126919a94c49c0fb7ee2fb3 ]

If blk_mq_init_queue() returns an error, it gets assigned to
vblk->disk->queue. Then, when we call put_disk(), we end up calling
blk_put_queue() with the ERR_PTR, causing a bad dereference. Fix it by
only assigning to vblk->disk->queue on success.

Signed-off-by: Omar Sandoval 
Reviewed-by: Jeff Moyer 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nbd: blk_mq_init_queue returns an error code on failure, not NULL

2017-08-11T15:49:36+00:00

[ Upstream commit 25b4acfc7de0fc4da3bfea3a316f7282c6fbde81 ]

Additionally, don't assign directly to disk->queue, otherwise
blk_put_queue (called via put_disk) will choke (panic) on the errno
stored there.

Bug found by code inspection after Omar found a similar issue in
virtio_blk.  Compile-tested only.

Signed-off-by: Jeff Moyer 
Reviewed-by: Omar Sandoval 
Reviewed-by: Josef Bacik 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/blkback: don't free be structure too early

2017-07-05T12:40:20+00:00

commit 71df1d7ccad1c36f7321d6b3b48f2ea42681c363 upstream.

The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen/blkback: don't use xen_blkif_get() in xen-blkback kthread

2017-07-05T12:40:17+00:00

commit a24fa22ce22ae302b3bf8f7008896d52d5d57b8d upstream.

There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple rings.

Setting ring->xenblkd to NULL after stopping the kthread isn't needed
as the kthread does this already.

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen-blkback: don't leak stack data via response ring

2017-06-29T11:00:27+00:00

commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 upstream.

Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).

This is XSA-216.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen/blkback: fix disconnect while I/Os in flight

2017-06-29T11:00:27+00:00

commit 46464411307746e6297a034a9983a22c9dfc5a0c upstream.

Today disconnecting xen-blkback is broken in case there are still
I/Os in flight: xen_blkif_disconnect() will bail out early without
releasing all resources in the hope it will be called again when
the last request has terminated. This, however, won't happen as
xen_blkif_free() won't be called on termination of the last running
request: xen_blkif_put() won't decrement the blkif refcnt to 0 as
xen_blkif_disconnect() didn't finish before thus some xen_blkif_put()
calls in xen_blkif_disconnect() didn't happen.

To solve this deadlock xen_blkif_disconnect() and
xen_blkif_alloc_rings() shouldn't use xen_blkif_put() and
xen_blkif_get() but use some other way to do their accounting of
resources.

This at once fixes another error in xen_blkif_disconnect(): when it
returned early with -EBUSY for another ring than 0 it would call
xen_blkif_put() again for already handled rings on a subsequent call.
This will lead to inconsistencies in the refcnt handling.

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

nbd: fix 64-bit division

2017-04-21T07:31:23+00:00

commit e88f72cb9f54f6d244e55f629fe5e2f34ca6f9ed upstream.

We have this:

ERROR: "__aeabi_ldivmod" [drivers/block/nbd.ko] undefined!
ERROR: "__divdi3" [drivers/block/nbd.ko] undefined!
nbd.c:(.text+0x247c72): undefined reference to `__divdi3'

due to a recent commit, that did 64-bit division. Use the proper
divider function so that 32-bit compiles don't break.

Fixes: ef77b515243b ("nbd: use loff_t for blocksize and nbd_set_size args")
Signed-off-by: Jens Axboe 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman