1. 08 Jun, 2016 2 commits
    • Bob Liu's avatar
      xen-blkfront: fix resume issues after a migration · 2a6f71ad
      Bob Liu authored
      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: default avatarBob Liu <bob.liu@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2a6f71ad
    • Bob Liu's avatar
      xen-blkfront: don't call talk_to_blkback when already connected to blkback · efd15352
      Bob Liu authored
      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: default avatarBob Liu <bob.liu@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      efd15352
  2. 06 May, 2016 28 commits
  3. 03 May, 2016 1 commit
    • Keith Busch's avatar
      NVMe: Fix reset/remove race · 87c32077
      Keith Busch authored
      This fixes a scenario where device is present and being reset, but a
      request to unbind the driver occurs.
      
      A previous patch series addressing a device failure removal scenario
      flushed reset_work after controller disable to unblock reset_work waiting
      on a completion that wouldn't occur. This isn't safe as-is. The broken
      scenario can potentially be induced with:
      
        modprobe nvme && modprobe -r nvme
      
      To fix, the reset work is flushed immediately after setting the controller
      removing flag, and any subsequent reset will not proceed with controller
      initialization if the flag is set.
      
      The controller status must be polled while active, so the watchdog timer
      is also left active until the controller is disabled to cleanup requests
      that may be stuck during namespace removal.
      
      [Fixes: ff23a2a1]
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      87c32077
  4. 02 May, 2016 9 commits