linux-stable.git/drivers/block, branch linux-4.6.y

xen-blkfront: don't call talk_to_blkback when already connected to blkback

2016-08-10T10:54:44+00:00

commit efd1535270c1deb0487527bf0c3c827301a69c93 upstream.

Sometimes blkfront may twice receive blkback_changed() notification
(XenbusStateConnected) after migration, which will cause
talk_to_blkback() to be called twice too and confuse xen-blkback.

The flow is as follow:
   blkfront                                        blkback
blkfront_resume()
 > talk_to_blkback()
  > Set blkfront to XenbusStateInitialised
                                                front changed()
                                                 > Connect()
                                                  > Set blkback to XenbusStateConnected

blkback_changed()
 > Skip talk_to_blkback()
   because frontstate == XenbusStateInitialised
 > blkfront_connect()
  > Set blkfront to XenbusStateConnected

-----
And here we get another XenbusStateConnected notification leading
to:
-----
blkback_changed()
 > because now frontstate != XenbusStateInitialised
   talk_to_blkback() is also called again
  > blkfront state changed from
  XenbusStateConnected to XenbusStateInitialised
    (Which is not correct!)

						front_changed():
                                                 > Do nothing because blkback
                                                   already in XenbusStateConnected

Now blkback is in XenbusStateConnected but blkfront is still
in XenbusStateInitialised - leading to no disks.

Poking of the XenbusStateConnected state is allowed (to deal with
block disk change) and has to be dealt with. The most likely
cause of this bug are custom udev scripts hooking up the disks
and then validating the size.

Signed-off-by: Bob Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen-blkfront: fix resume issues after a migration

2016-08-10T10:54:44+00:00

commit 2a6f71ad99cabe436e70c3f5fcf58072cb3bc07f upstream.

After a migrate to another host (which may not have multiqueue
support), the number of rings (block hardware queues)
may be changed and the ring info structure will also be reallocated.

This patch fixes two related bugs:
 * call blk_mq_update_nr_hw_queues() to make blk-core know the number
   of hardware queues have been changed.
 * Don't store rinfo pointer to hctx->driver_data, because rinfo may be
   reallocated so use hctx->queue_num to get the rinfo structure instead.

Signed-off-by: Bob Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen-blkfront: save uncompleted reqs in blkfront_resume()

2016-08-10T10:54:44+00:00

commit 7b427a59538a98161321aa46c13f4ea81b43f4eb upstream.

Uncompleted reqs used to be 'saved and resubmitted' in blkfront_recover() during
migration, but that's too late after multi-queue was introduced.

After a migrate to another host (which may not have multiqueue support), the
number of rings (block hardware queues) may be changed and the ring and shadow
structure will also be reallocated.

The blkfront_recover() then can't 'save and resubmit' the real
uncompleted reqs because shadow structure have been reallocated.

This patch fixes this issue by moving the 'save' logic out of
blkfront_recover() to earlier place in blkfront_resume().

The 'resubmit' is not changed and still in blkfront_recover().

Signed-off-by: Bob Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

rbd: report unsupported features to syslog

2016-04-28T08:07:43+00:00

... instead of just returning an error.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin

rbd: fix rbd map vs notify races

2016-04-28T08:07:22+00:00

A while ago, commit 9875201e1049 ("rbd: fix use-after free of
rbd_dev->disk") fixed rbd unmap vs notify race by introducing
an exported wrapper for flushing notifies and sticking it into
do_rbd_remove().

A similar problem exists on the rbd map path, though: the watch is
registered in rbd_dev_image_probe(), while the disk is set up quite
a few steps later, in rbd_dev_device_setup().  Nothing prevents
a notify from coming in and crashing on a NULL rbd_dev->disk:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
    Call Trace:
     [] rbd_watch_cb+0x34/0x180 [rbd]
     [] do_event_work+0x40/0xb0 [libceph]
     [] process_one_work+0x17b/0x470
     [] worker_thread+0x11b/0x400
     [] ? rescuer_thread+0x400/0x400
     [] kthread+0xcf/0xe0
     [] ? finish_task_switch+0x53/0x170
     [] ? kthread_create_on_node+0x140/0x140
     [] ret_from_fork+0x58/0x90
     [] ? kthread_create_on_node+0x140/0x140
    RIP  [] rbd_dev_refresh+0xfa/0x180 [rbd]

If an error occurs during rbd map, we have to error out, potentially
tearing down a watch.  Just like on rbd unmap, notifies have to be
flushed, otherwise rbd_watch_cb() may end up trying to read in the
image header after rbd_dev_image_release() has run:

    Assertion failure in rbd_dev_header_info() at line 4722:

     rbd_assert(rbd_image_format_valid(rbd_dev->image_format));

    Call Trace:
     [] ? rbd_parent_request_create+0x150/0x150
     [] rbd_dev_refresh+0x59/0x390
     [] rbd_watch_cb+0x69/0x290
     [] do_event_work+0x10f/0x1c0
     [] process_one_work+0x689/0x1a80
     [] ? process_one_work+0x5e7/0x1a80
     [] ? finish_task_switch+0x225/0x640
     [] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
     [] worker_thread+0xd9/0x1320
     [] ? process_one_work+0x1a80/0x1a80
     [] kthread+0x21d/0x2e0
     [] ? kthread_stop+0x550/0x550
     [] ret_from_fork+0x22/0x40
     [] ? kthread_stop+0x550/0x550
    RIP  [] rbd_dev_header_info+0xa19/0x1e30

To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling
revalidate_disk(), b) move ceph_osdc_flush_notifies() call into
rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn
header read-in into a critical section.  The latter also happens to
take care of rbd map foo@bar vs rbd snap rm foo@bar race.

Fixes: http://tracker.ceph.com/issues/15490

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin

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

2016-04-15T22:44:10+00:00

Pull block fixes from Jens Axboe:
 "A few fixes for the current series. This contains:

   - Two fixes for NVMe:

     One fixes a reset race that can be triggered by repeated
     insert/removal of the module.

     The other fixes an issue on some platforms, where we get probe
     timeouts since legacy interrupts isn't working.  This used not to
     be a problem since we had the worker thread poll for completions,
     but since that was killed off, it means those poor souls can't
     successfully probe their NVMe device.  Use a proper IRQ check and
     probe (msi-x -> msi ->legacy), like most other drivers to work
     around this.  Both from Keith.

   - A loop corruption issue with offset in iters, from Ming Lei.

   - A fix for not having the partition stat per cpu ref count
     initialized before sending out the KOBJ_ADD, which could cause user
     space to access the counter prior to initialization.  Also from
     Ming Lei.

   - A fix for using the wrong congestion state, from Kaixu Xia"

* 'for-linus' of git://git.kernel.dk/linux-block:
  block: loop: fix filesystem corruption in case of aio/dio
  NVMe: Always use MSI/MSI-x interrupts
  NVMe: Fix reset/remove race
  writeback: fix the wrong congested state variable definition
  block: partition: initialize percpuref before sending out KOBJ_ADD

block: loop: fix filesystem corruption in case of aio/dio

2016-04-15T14:25:56+00:00

Starting from commit e36f620428(block: split bios to max possible length),
block core starts to split bio in the middle of bvec.

Unfortunately loop dio/aio doesn't consider this situation, and
always treat 'iter.iov_offset' as zero. Then filesystem corruption
is observed.

This patch figures out the offset of the base bvevc via
'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
to iov iterator.

Fixes: e36f6204288088f (block: split bios to max possible length)
Cc: Keith Busch 
Cc: Al Viro 
Cc: stable@vger.kernel.org (4.5)
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client

2016-04-07T23:34:26+00:00

Pull Ceph fix from Sage Weil:
 "This just fixes a few remaining memory allocations in RBD to use
  GFP_NOIO instead of GFP_ATOMIC"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  rbd: use GFP_NOIO consistently for request allocations

rbd: use GFP_NOIO consistently for request allocations

2016-04-05T20:11:37+00:00

As of 5a60e87603c4c533492c515b7f62578189b03c9c, RBD object request
allocations are made via rbd_obj_request_create() with GFP_NOIO.
However, subsequent OSD request allocations in rbd_osd_req_create*()
use GFP_ATOMIC.

With heavy page cache usage (e.g. OSDs running on same host as krbd
client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
observed to fail, where direct reclaim would have allowed GFP_NOIO
allocations to succeed.

Cc: stable@vger.kernel.org # 3.18+
Suggested-by: Vlastimil Babka 
Suggested-by: Neil Brown 
Signed-off-by: David Disseldorp 
Signed-off-by: Ilya Dryomov

mm, fs: remove remaining PAGE_CACHE_* and page_cache_{get,release} usage

2016-04-04T17:41:08+00:00

Mostly direct substitution with occasional adjustment or removing
outdated comments.

Signed-off-by: Kirill A. Shutemov 
Acked-by: Michal Hocko 
Signed-off-by: Linus Torvalds