linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/md.c

between commit:

  57a0f3a81ef2 ("Revert "md: add md_submit_discard_bio() for submitting discard 
bio"")

from Linus' tree and commit:

  1c02fca620f7 ("block: remove the request_queue argument to the 
block_bio_remap tracepoint")

from the block tree.

I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpZbpaLftKyV.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  fs/io_uring.c

between commits:

  4eb8dded6b82 ("io_uring: fix openat/openat2 unified prep handling")
  f5cac8b156e8 ("io_uring: don't use retry based buffered reads for non-async 
bdev")

from Linus' tree and commit:

  76c917267129 ("io_uring: get rid of req->io/io_async_ctx union")
  8f95cf7f28bf ("io_uring: enable file table usage for SQPOLL rings")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/io_uring.c
index c9aea6c44372,7ee5e18218c2..
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@@ -3128,12 -3172,12 +3187,13 @@@ static int io_read(struct io_kiocb *req
struct iovec inline_vecs[UIO_FASTIOV], *iovec = inline_vecs;
struct kiocb *kiocb = >rw.kiocb;
struct iov_iter __iter, *iter = &__iter;
+   struct io_async_rw *rw = req->async_data;
ssize_t io_size, ret, ret2;
size_t iov_count;
 +  bool no_async;
  
-   if (req->io)
-   iter = >io->rw.iter;
+   if (rw)
+   iter = >iter;
  
ret = io_import_iovec(READ, req, , iter, !force_nonblock);
if (ret < 0)
@@@ -3193,8 -3236,7 +3253,9 @@@ copy_iov
ret = ret2;
goto out_free;
}
 +  if (no_async)
 +  return -EAGAIN;
+   rw = req->async_data;
/* it's copied and will be cleaned with ->io */
iovec = NULL;
/* now use our persistent iterator, if we aren't already */


pgp_YojSMGvog.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 4/14/19 9:06 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   include/linux/bvec.h
> 
> between commit:
> 
>   1200e07f3ad4 ("block: don't use for-inside-for in bio_for_each_segment_all")
> 
> from Linus' tree and commit:
> 
>   52d52d1c98a9 ("block: only allow contiguous page structs in a bio_vec")
> 
> from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks fine Stephen - but due to this and the BFQ one, I've merged in
5.1-rc5 and resolved them as well. Tomorrow's branch should merge
cleanly for you.

-- 
Jens Axboe

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  include/linux/bvec.h

between commit:

  1200e07f3ad4 ("block: don't use for-inside-for in bio_for_each_segment_all")

from Linus' tree and commit:

  52d52d1c98a9 ("block: only allow contiguous page structs in a bio_vec")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/bvec.h
index 3bc91879e1e2,44b0f4684190..
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@@ -156,8 -151,8 +151,8 @@@ static inline void bvec_advance(const s
  {
struct bio_vec *bv = _all->bv;
  
 -  if (bv->bv_page) {
 +  if (iter_all->done) {
-   bv->bv_page = nth_page(bv->bv_page, 1);
+   bv->bv_page++;
bv->bv_offset = 0;
} else {
bv->bv_page = bvec->bv_page;


pgppe2Il3Bc9I.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  block/bfq-iosched.c

between commit:

  eed47d19d936 ("block, bfq: fix use after free in bfq_bfqq_expire")

from Linus' tree and commit:

  636b8fe86bed ("block, bfq: fix some typos in comments")

from the block tree.

I fixed it up (the former included the fix from the latter, so I just
used that) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpiKr3dDC2JG.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  include/linux/fs.h

between commit:

  84c4e1f89fef ("aio: simplify - and fix - fget/fput for io_submit()")

from Linus' tree and commit:

  fb7e160019f4 ("fs: add an iopoll method to struct file_operations")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/fs.h
index 76c7205d4f0d,80e1b199a4b1..
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@@ -317,9 -310,8 +317,10 @@@ struct kiocb 
int ki_flags;
u16 ki_hint;
u16 ki_ioprio; /* See linux/ioprio.h */
+   unsigned intki_cookie; /* for ->iopoll */
 -} __randomize_layout;
 +
 +  randomized_struct_fields_end
 +};
  
  static inline bool is_sync_kiocb(struct kiocb *kiocb)
  {


pgpV_X8eUXCiu.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 11/15/18 7:19 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/blk.h
> 
> between commit:
> 
>   1adfc5e4136f ("block: make sure discard bio is aligned with logical block 
> size")
> 
> from Linus' tree (precedes v4.20-rc2) and commit:
> 
>   079076b3416e ("block: remove deadline __deadline manipulation helpers")
> 
> from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen, there's a few coming up. Come Sunday I'll pull in
-rc3 and resolve these. Not just for that, but also to ensure that
my -next branch has some important fixes from this series.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 11/15/18 7:19 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/blk.h
> 
> between commit:
> 
>   1adfc5e4136f ("block: make sure discard bio is aligned with logical block 
> size")
> 
> from Linus' tree (precedes v4.20-rc2) and commit:
> 
>   079076b3416e ("block: remove deadline __deadline manipulation helpers")
> 
> from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen, there's a few coming up. Come Sunday I'll pull in
-rc3 and resolve these. Not just for that, but also to ensure that
my -next branch has some important fixes from this series.

-- 
Jens Axboe

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  block/blk.h

between commit:

  1adfc5e4136f ("block: make sure discard bio is aligned with logical block 
size")

from Linus' tree (precedes v4.20-rc2) and commit:

  079076b3416e ("block: remove deadline __deadline manipulation helpers")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk.h
index 0089fefdf771,027a0ccc175e..
--- a/block/blk.h
+++ b/block/blk.h
@@@ -380,31 -233,6 +233,16 @@@ static inline void req_set_nomerge(stru
q->last_merge = NULL;
  }
  
- /*
-  * Steal a bit from this field for legacy IO path atomic IO marking. Note that
-  * setting the deadline clears the bottom bit, potentially clearing the
-  * completed bit. The user has to be OK with this (current ones are fine).
-  */
- static inline void blk_rq_set_deadline(struct request *rq, unsigned long time)
- {
-   rq->__deadline = time & ~0x1UL;
- }
- 
- static inline unsigned long blk_rq_deadline(struct request *rq)
- {
-   return rq->__deadline & ~0x1UL;
- }
- 
 +/*
 + * The max size one bio can handle is UINT_MAX becasue bvec_iter.bi_size
 + * is defined as 'unsigned int', meantime it has to aligned to with logical
 + * block size which is the minimum accepted unit by hardware.
 + */
 +static inline unsigned int bio_allowed_max_sectors(struct request_queue *q)
 +{
 +  return round_down(UINT_MAX, queue_logical_block_size(q)) >> 9;
 +}
 +
  /*
   * Internal io_context interface
   */


pgpfyhYR9szte.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  block/blk.h

between commit:

  1adfc5e4136f ("block: make sure discard bio is aligned with logical block 
size")

from Linus' tree (precedes v4.20-rc2) and commit:

  079076b3416e ("block: remove deadline __deadline manipulation helpers")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk.h
index 0089fefdf771,027a0ccc175e..
--- a/block/blk.h
+++ b/block/blk.h
@@@ -380,31 -233,6 +233,16 @@@ static inline void req_set_nomerge(stru
q->last_merge = NULL;
  }
  
- /*
-  * Steal a bit from this field for legacy IO path atomic IO marking. Note that
-  * setting the deadline clears the bottom bit, potentially clearing the
-  * completed bit. The user has to be OK with this (current ones are fine).
-  */
- static inline void blk_rq_set_deadline(struct request *rq, unsigned long time)
- {
-   rq->__deadline = time & ~0x1UL;
- }
- 
- static inline unsigned long blk_rq_deadline(struct request *rq)
- {
-   return rq->__deadline & ~0x1UL;
- }
- 
 +/*
 + * The max size one bio can handle is UINT_MAX becasue bvec_iter.bi_size
 + * is defined as 'unsigned int', meantime it has to aligned to with logical
 + * block size which is the minimum accepted unit by hardware.
 + */
 +static inline unsigned int bio_allowed_max_sectors(struct request_queue *q)
 +{
 +  return round_down(UINT_MAX, queue_logical_block_size(q)) >> 9;
 +}
 +
  /*
   * Internal io_context interface
   */


pgpfyhYR9szte.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/rdma.c

between commit:

  b925a2dc165e ("nvme-rdma: default MR page size to 4k")

from Linus' tree and commits:

  90af35123d3b ("nvme-rdma: move nvme_rdma_configure_admin_queue code location")
  a7b7c7a105a5 ("nvme-rdma: Use unlikely macro in the fast path")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/rdma.c
index a7f7d0ae3331,6a7682620d87..
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@@ -605,10 -629,9 +626,10 @@@ out_stop_queues
return ret;
  }
  
- static int nvme_rdma_init_io_queues(struct nvme_rdma_ctrl *ctrl)
+ static int nvme_rdma_alloc_io_queues(struct nvme_rdma_ctrl *ctrl)
  {
struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
 +  struct ib_device *ibdev = ctrl->device->dev;
unsigned int nr_io_queues;
int i, ret;
  
@@@ -656,10 -734,144 +741,144 @@@ static void nvme_rdma_destroy_admin_que
  {
nvme_rdma_free_qe(ctrl->queues[0].device->dev, >async_event_sqe,
sizeof(struct nvme_command), DMA_TO_DEVICE);
-   nvme_rdma_stop_and_free_queue(>queues[0]);
-   blk_cleanup_queue(ctrl->ctrl.admin_q);
-   blk_mq_free_tag_set(>admin_tag_set);
-   nvme_rdma_dev_put(ctrl->device);
+   nvme_rdma_stop_queue(>queues[0]);
+   if (remove) {
+   blk_cleanup_queue(ctrl->ctrl.admin_q);
+   nvme_rdma_free_tagset(>ctrl, true);
+   }
+   nvme_rdma_free_queue(>queues[0]);
+ }
+ 
+ static int nvme_rdma_configure_admin_queue(struct nvme_rdma_ctrl *ctrl,
+   bool new)
+ {
+   int error;
+ 
+   error = nvme_rdma_alloc_queue(ctrl, 0, NVME_AQ_DEPTH);
+   if (error)
+   return error;
+ 
+   ctrl->device = ctrl->queues[0].device;
+ 
+   ctrl->max_fr_pages = min_t(u32, NVME_RDMA_MAX_SEGMENTS,
+   ctrl->device->dev->attrs.max_fast_reg_page_list_len);
+ 
+   if (new) {
+   ctrl->ctrl.admin_tagset = nvme_rdma_alloc_tagset(>ctrl, 
true);
+   if (IS_ERR(ctrl->ctrl.admin_tagset))
+   goto out_free_queue;
+ 
+   ctrl->ctrl.admin_q = blk_mq_init_queue(>admin_tag_set);
+   if (IS_ERR(ctrl->ctrl.admin_q)) {
+   error = PTR_ERR(ctrl->ctrl.admin_q);
+   goto out_free_tagset;
+   }
+   } else {
+   error = blk_mq_reinit_tagset(>admin_tag_set,
+nvme_rdma_reinit_request);
+   if (error)
+   goto out_free_queue;
+   }
+ 
+   error = nvme_rdma_start_queue(ctrl, 0);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   error = ctrl->ctrl.ops->reg_read64(>ctrl, NVME_REG_CAP,
+   >ctrl.cap);
+   if (error) {
+   dev_err(ctrl->ctrl.device,
+   "prop_get NVME_REG_CAP failed\n");
+   goto out_cleanup_queue;
+   }
+ 
+   ctrl->ctrl.sqsize =
+   min_t(int, NVME_CAP_MQES(ctrl->ctrl.cap), ctrl->ctrl.sqsize);
+ 
+   error = nvme_enable_ctrl(>ctrl, ctrl->ctrl.cap);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   ctrl->ctrl.max_hw_sectors =
 -  (ctrl->max_fr_pages - 1) << (PAGE_SHIFT - 9);
++  (ctrl->max_fr_pages - 1) << (ilog2(SZ_4K) - 9);
+ 
+   error = nvme_init_identify(>ctrl);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   error = nvme_rdma_alloc_qe(ctrl->queues[0].device->dev,
+   >async_event_sqe, sizeof(struct nvme_command),
+   DMA_TO_DEVICE);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   return 0;
+ 
+ out_cleanup_queue:
+   if (new)
+   blk_cleanup_queue(ctrl->ctrl.admin_q);
+ out_free_tagset:
+   if (new)
+   nvme_rdma_free_tagset(>ctrl, true);
+ out_free_queue:
+   nvme_rdma_free_queue(>queues[0]);
+   return error;
+ }
+ 
+ static void nvme_rdma_destroy_io_queues(struct nvme_rdma_ctrl *ctrl,
+   bool remove)
+ {
+   nvme_rdma_stop_io_queues(ctrl);
+   if (remove) {
+   blk_cleanup_queue(ctrl->ctrl.connect_q);
+   nvme_rdma_free_tagset(>ctrl, false);
+   }
+   nvme_rdma_free_io_queues(ctrl);
+ }
+ 
+ static int nvme_rdma_configure_io_queues(struct nvme_rdma_ctrl *ctrl, bool 
new)
+ {
+   int ret;
+ 
+   ret = nvme_rdma_alloc_io_queues(ctrl);
+   if (ret)
+   return ret;
+ 
+  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/rdma.c

between commit:

  b925a2dc165e ("nvme-rdma: default MR page size to 4k")

from Linus' tree and commits:

  90af35123d3b ("nvme-rdma: move nvme_rdma_configure_admin_queue code location")
  a7b7c7a105a5 ("nvme-rdma: Use unlikely macro in the fast path")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/rdma.c
index a7f7d0ae3331,6a7682620d87..
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@@ -605,10 -629,9 +626,10 @@@ out_stop_queues
return ret;
  }
  
- static int nvme_rdma_init_io_queues(struct nvme_rdma_ctrl *ctrl)
+ static int nvme_rdma_alloc_io_queues(struct nvme_rdma_ctrl *ctrl)
  {
struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
 +  struct ib_device *ibdev = ctrl->device->dev;
unsigned int nr_io_queues;
int i, ret;
  
@@@ -656,10 -734,144 +741,144 @@@ static void nvme_rdma_destroy_admin_que
  {
nvme_rdma_free_qe(ctrl->queues[0].device->dev, >async_event_sqe,
sizeof(struct nvme_command), DMA_TO_DEVICE);
-   nvme_rdma_stop_and_free_queue(>queues[0]);
-   blk_cleanup_queue(ctrl->ctrl.admin_q);
-   blk_mq_free_tag_set(>admin_tag_set);
-   nvme_rdma_dev_put(ctrl->device);
+   nvme_rdma_stop_queue(>queues[0]);
+   if (remove) {
+   blk_cleanup_queue(ctrl->ctrl.admin_q);
+   nvme_rdma_free_tagset(>ctrl, true);
+   }
+   nvme_rdma_free_queue(>queues[0]);
+ }
+ 
+ static int nvme_rdma_configure_admin_queue(struct nvme_rdma_ctrl *ctrl,
+   bool new)
+ {
+   int error;
+ 
+   error = nvme_rdma_alloc_queue(ctrl, 0, NVME_AQ_DEPTH);
+   if (error)
+   return error;
+ 
+   ctrl->device = ctrl->queues[0].device;
+ 
+   ctrl->max_fr_pages = min_t(u32, NVME_RDMA_MAX_SEGMENTS,
+   ctrl->device->dev->attrs.max_fast_reg_page_list_len);
+ 
+   if (new) {
+   ctrl->ctrl.admin_tagset = nvme_rdma_alloc_tagset(>ctrl, 
true);
+   if (IS_ERR(ctrl->ctrl.admin_tagset))
+   goto out_free_queue;
+ 
+   ctrl->ctrl.admin_q = blk_mq_init_queue(>admin_tag_set);
+   if (IS_ERR(ctrl->ctrl.admin_q)) {
+   error = PTR_ERR(ctrl->ctrl.admin_q);
+   goto out_free_tagset;
+   }
+   } else {
+   error = blk_mq_reinit_tagset(>admin_tag_set,
+nvme_rdma_reinit_request);
+   if (error)
+   goto out_free_queue;
+   }
+ 
+   error = nvme_rdma_start_queue(ctrl, 0);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   error = ctrl->ctrl.ops->reg_read64(>ctrl, NVME_REG_CAP,
+   >ctrl.cap);
+   if (error) {
+   dev_err(ctrl->ctrl.device,
+   "prop_get NVME_REG_CAP failed\n");
+   goto out_cleanup_queue;
+   }
+ 
+   ctrl->ctrl.sqsize =
+   min_t(int, NVME_CAP_MQES(ctrl->ctrl.cap), ctrl->ctrl.sqsize);
+ 
+   error = nvme_enable_ctrl(>ctrl, ctrl->ctrl.cap);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   ctrl->ctrl.max_hw_sectors =
 -  (ctrl->max_fr_pages - 1) << (PAGE_SHIFT - 9);
++  (ctrl->max_fr_pages - 1) << (ilog2(SZ_4K) - 9);
+ 
+   error = nvme_init_identify(>ctrl);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   error = nvme_rdma_alloc_qe(ctrl->queues[0].device->dev,
+   >async_event_sqe, sizeof(struct nvme_command),
+   DMA_TO_DEVICE);
+   if (error)
+   goto out_cleanup_queue;
+ 
+   return 0;
+ 
+ out_cleanup_queue:
+   if (new)
+   blk_cleanup_queue(ctrl->ctrl.admin_q);
+ out_free_tagset:
+   if (new)
+   nvme_rdma_free_tagset(>ctrl, true);
+ out_free_queue:
+   nvme_rdma_free_queue(>queues[0]);
+   return error;
+ }
+ 
+ static void nvme_rdma_destroy_io_queues(struct nvme_rdma_ctrl *ctrl,
+   bool remove)
+ {
+   nvme_rdma_stop_io_queues(ctrl);
+   if (remove) {
+   blk_cleanup_queue(ctrl->ctrl.connect_q);
+   nvme_rdma_free_tagset(>ctrl, false);
+   }
+   nvme_rdma_free_io_queues(ctrl);
+ }
+ 
+ static int nvme_rdma_configure_io_queues(struct nvme_rdma_ctrl *ctrl, bool 
new)
+ {
+   int ret;
+ 
+   ret = nvme_rdma_alloc_io_queues(ctrl);
+   if (ret)
+   return ret;
+ 
+  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/block_dev.c

between commit:

  9ae3b3f52c62 ("block: provide bio_uninit() free freeing integrity/task 
associations")

from Linus' tree and commit:

  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/block_dev.c
index 9e9f25dc69bc,2c5f08696fff..
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@@ -262,11 -263,8 +263,11 @@@ __blkdev_direct_IO_simple(struct kiocb 
if (vecs != inline_vecs)
kfree(vecs);
  
-   if (unlikely(bio.bi_error))
-   ret = bio.bi_error;
+   if (unlikely(bio.bi_status))
 -  return blk_status_to_errno(bio.bi_status);
++  ret = blk_status_to_errno(bio.bi_status);
 +
 +  bio_uninit();
 +
return ret;
  }
  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/block_dev.c

between commit:

  9ae3b3f52c62 ("block: provide bio_uninit() free freeing integrity/task 
associations")

from Linus' tree and commit:

  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/block_dev.c
index 9e9f25dc69bc,2c5f08696fff..
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@@ -262,11 -263,8 +263,11 @@@ __blkdev_direct_IO_simple(struct kiocb 
if (vecs != inline_vecs)
kfree(vecs);
  
-   if (unlikely(bio.bi_error))
-   ret = bio.bi_error;
+   if (unlikely(bio.bi_status))
 -  return blk_status_to_errno(bio.bi_status);
++  ret = blk_status_to_errno(bio.bi_status);
 +
 +  bio_uninit();
 +
return ret;
  }
  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm-raid1.c

between commit:

  cd15fb64ee56 ("Revert "dm mirror: use all available legs on multiple 
failures"")

from Linus' tree and commits:

  9966afaf91b3 ("dm: fix REQ_RAHEAD handling")
  1be569098458 ("dm: change ->end_io calling convention")
  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/md/dm-raid1.c
index 4da8858856fb,3ab584b686e0..
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@@ -1255,26 -1253,16 +1256,26 @@@ static int mirror_end_io(struct dm_targ
if (!(bio->bi_opf & REQ_PREFLUSH) &&
bio_op(bio) != REQ_OP_DISCARD)
dm_rh_dec(ms->rh, bio_record->write_region);
-   return error;
+   return DM_ENDIO_DONE;
}
  
-   if (error == -EOPNOTSUPP)
+   if (*error == BLK_STS_NOTSUPP)
 -  return DM_ENDIO_DONE;
 +  goto out;
  
-   if ((error == -EWOULDBLOCK) && (bio->bi_opf & REQ_RAHEAD))
+   if (bio->bi_opf & REQ_RAHEAD)
 -  return DM_ENDIO_DONE;
 +  goto out;
  
-   if (unlikely(error)) {
+   if (unlikely(*error)) {
 +  if (!bio_record->details.bi_bdev) {
 +  /*
 +   * There wasn't enough memory to record necessary
 +   * information for a retry or there was no other
 +   * mirror in-sync.
 +   */
 +  DMERR_LIMIT("Mirror read failed.");
-   return -EIO;
++  return BLK_STS_IOERR;
 +  }
 +
m = bio_record->m;
  
DMERR("Mirror read failed from %s. Trying alternative device.",
@@@ -1290,8 -1278,7 +1291,8 @@@
bd = _record->details;
  
dm_bio_restore(bd, bio);
 +  bio_record->details.bi_bdev = NULL;
-   bio->bi_error = 0;
+   bio->bi_status = 0;
  
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;
@@@ -1299,10 -1286,7 +1300,10 @@@
DMERR("All replicated volumes dead, failing I/O");
}
  
 +out:
 +  bio_record->details.bi_bdev = NULL;
 +
-   return error;
+   return DM_ENDIO_DONE;
  }
  
  static void mirror_presuspend(struct dm_target *ti)

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm-raid1.c

between commit:

  cd15fb64ee56 ("Revert "dm mirror: use all available legs on multiple 
failures"")

from Linus' tree and commits:

  9966afaf91b3 ("dm: fix REQ_RAHEAD handling")
  1be569098458 ("dm: change ->end_io calling convention")
  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/md/dm-raid1.c
index 4da8858856fb,3ab584b686e0..
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@@ -1255,26 -1253,16 +1256,26 @@@ static int mirror_end_io(struct dm_targ
if (!(bio->bi_opf & REQ_PREFLUSH) &&
bio_op(bio) != REQ_OP_DISCARD)
dm_rh_dec(ms->rh, bio_record->write_region);
-   return error;
+   return DM_ENDIO_DONE;
}
  
-   if (error == -EOPNOTSUPP)
+   if (*error == BLK_STS_NOTSUPP)
 -  return DM_ENDIO_DONE;
 +  goto out;
  
-   if ((error == -EWOULDBLOCK) && (bio->bi_opf & REQ_RAHEAD))
+   if (bio->bi_opf & REQ_RAHEAD)
 -  return DM_ENDIO_DONE;
 +  goto out;
  
-   if (unlikely(error)) {
+   if (unlikely(*error)) {
 +  if (!bio_record->details.bi_bdev) {
 +  /*
 +   * There wasn't enough memory to record necessary
 +   * information for a retry or there was no other
 +   * mirror in-sync.
 +   */
 +  DMERR_LIMIT("Mirror read failed.");
-   return -EIO;
++  return BLK_STS_IOERR;
 +  }
 +
m = bio_record->m;
  
DMERR("Mirror read failed from %s. Trying alternative device.",
@@@ -1290,8 -1278,7 +1291,8 @@@
bd = _record->details;
  
dm_bio_restore(bd, bio);
 +  bio_record->details.bi_bdev = NULL;
-   bio->bi_error = 0;
+   bio->bi_status = 0;
  
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;
@@@ -1299,10 -1286,7 +1300,10 @@@
DMERR("All replicated volumes dead, failing I/O");
}
  
 +out:
 +  bio_record->details.bi_bdev = NULL;
 +
-   return error;
+   return DM_ENDIO_DONE;
  }
  
  static void mirror_presuspend(struct dm_target *ti)

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm-io.c

between commit:

  feb7695fe9fb ("dm io: fix duplicate bio completion due to missing ref count")

from Linus' tree and commit:

  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/md/dm-io.c
index 8d5ca30f6551,81248a8a8b57..
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@@ -317,9 -318,9 +318,9 @@@ static void do_region(int op, int op_fl
else if (op == REQ_OP_WRITE_SAME)
special_cmd_max_sectors = q->limits.max_write_same_sectors;
if ((op == REQ_OP_DISCARD || op == REQ_OP_WRITE_ZEROES ||
 -   op == REQ_OP_WRITE_SAME)  &&
 -  special_cmd_max_sectors == 0) {
 +   op == REQ_OP_WRITE_SAME) && special_cmd_max_sectors == 0) {
 +  atomic_inc(>count);
-   dec_count(io, region, -EOPNOTSUPP);
+   dec_count(io, region, BLK_STS_NOTSUPP);
return;
}
  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm-io.c

between commit:

  feb7695fe9fb ("dm io: fix duplicate bio completion due to missing ref count")

from Linus' tree and commit:

  4e4cbee93d56 ("block: switch bios to blk_status_t")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/md/dm-io.c
index 8d5ca30f6551,81248a8a8b57..
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@@ -317,9 -318,9 +318,9 @@@ static void do_region(int op, int op_fl
else if (op == REQ_OP_WRITE_SAME)
special_cmd_max_sectors = q->limits.max_write_same_sectors;
if ((op == REQ_OP_DISCARD || op == REQ_OP_WRITE_ZEROES ||
 -   op == REQ_OP_WRITE_SAME)  &&
 -  special_cmd_max_sectors == 0) {
 +   op == REQ_OP_WRITE_SAME) && special_cmd_max_sectors == 0) {
 +  atomic_inc(>count);
-   dec_count(io, region, -EOPNOTSUPP);
+   dec_count(io, region, BLK_STS_NOTSUPP);
return;
}
  

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:33 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:27:04 -0600 Jens Axboe  wrote:
>>
>> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:  

 I'll cherry pick that commit into the 4.13 branch to get this resolved.  
>>>
>>> Merging commit 8e8320c9315c might give a better result ...  
>>
>> I don't want to pull the whole thing in, just that offending commit.
> 
> Your tree is already based on v4.12-rc5 so you are not really pulling
> much in at all:
> 
> $ git rev-list --count --no-merges 8e8320c9315c ^block/for-next 
> 14

Yeah good point, I guess not a lot has happened since -rc5.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:33 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:27:04 -0600 Jens Axboe  wrote:
>>
>> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:  

 I'll cherry pick that commit into the 4.13 branch to get this resolved.  
>>>
>>> Merging commit 8e8320c9315c might give a better result ...  
>>
>> I don't want to pull the whole thing in, just that offending commit.
> 
> Your tree is already based on v4.12-rc5 so you are not really pulling
> much in at all:
> 
> $ git rev-list --count --no-merges 8e8320c9315c ^block/for-next 
> 14

Yeah good point, I guess not a lot has happened since -rc5.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 22 Jun 2017 21:27:04 -0600 Jens Axboe  wrote:
>
> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:  
> >>
> >> I'll cherry pick that commit into the 4.13 branch to get this resolved.  
> > 
> > Merging commit 8e8320c9315c might give a better result ...  
> 
> I don't want to pull the whole thing in, just that offending commit.

Your tree is already based on v4.12-rc5 so you are not really pulling
much in at all:

$ git rev-list --count --no-merges 8e8320c9315c ^block/for-next 
14

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 22 Jun 2017 21:27:04 -0600 Jens Axboe  wrote:
>
> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:  
> >>
> >> I'll cherry pick that commit into the 4.13 branch to get this resolved.  
> > 
> > Merging commit 8e8320c9315c might give a better result ...  
> 
> I don't want to pull the whole thing in, just that offending commit.

Your tree is already based on v4.12-rc5 so you are not really pulling
much in at all:

$ git rev-list --count --no-merges 8e8320c9315c ^block/for-next 
14

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>>
>> I'll cherry pick that commit into the 4.13 branch to get this resolved.
> 
> Merging commit 8e8320c9315c might give a better result ...

To be clear, what I meant (and did) was cherry picking 8e8320c9315c
into for-4.13/block.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>>
>> I'll cherry pick that commit into the 4.13 branch to get this resolved.
> 
> Merging commit 8e8320c9315c might give a better result ...

To be clear, what I meant (and did) was cherry picking 8e8320c9315c
into for-4.13/block.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>>
>> I'll cherry pick that commit into the 4.13 branch to get this resolved.
> 
> Merging commit 8e8320c9315c might give a better result ...

I don't want to pull the whole thing in, just that offending commit.


-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>>
>> I'll cherry pick that commit into the 4.13 branch to get this resolved.
> 
> Merging commit 8e8320c9315c might give a better result ...

I don't want to pull the whole thing in, just that offending commit.


-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>
> I'll cherry pick that commit into the 4.13 branch to get this resolved.

Merging commit 8e8320c9315c might give a better result ...

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe  wrote:
>
> I'll cherry pick that commit into the 4.13 branch to get this resolved.

Merging commit 8e8320c9315c might give a better result ...

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:06 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/blk-mq-sched.c
> 
> between commit:
> 
>   8e8320c9315c ("blk-mq: fix performance regression with shared tags")
> 
> from Linus' tree and commits:
> 
>   d2c0d3832469 ("blk-mq: move blk_mq_sched_{get,put}_request to blk-mq.c")
>   44e8c2bff80b ("blk-mq: refactor blk_mq_sched_assign_ioc")
> 
> from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

I'll cherry pick that commit into the 4.13 branch to get this resolved.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 06/22/2017 09:06 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/blk-mq-sched.c
> 
> between commit:
> 
>   8e8320c9315c ("blk-mq: fix performance regression with shared tags")
> 
> from Linus' tree and commits:
> 
>   d2c0d3832469 ("blk-mq: move blk_mq_sched_{get,put}_request to blk-mq.c")
>   44e8c2bff80b ("blk-mq: refactor blk_mq_sched_assign_ioc")
> 
> from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

I'll cherry pick that commit into the 4.13 branch to get this resolved.

-- 
Jens Axboe

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-mq-sched.c

between commit:

  8e8320c9315c ("blk-mq: fix performance regression with shared tags")

from Linus' tree and commits:

  d2c0d3832469 ("blk-mq: move blk_mq_sched_{get,put}_request to blk-mq.c")
  44e8c2bff80b ("blk-mq: refactor blk_mq_sched_assign_ioc")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-mq-sched.c
index 0ded5e846335,191bf82d185e..
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@@ -47,131 -46,10 +46,49 @@@ void blk_mq_sched_assign_ioc(struct req
if (!icq)
return;
}
- 
+   get_io_context(icq->ioc);
rq->elv.icq = icq;
-   if (!blk_mq_sched_get_rq_priv(q, rq, bio)) {
-   rq->rq_flags |= RQF_ELVPRIV;
-   get_io_context(icq->ioc);
-   return;
-   }
- 
-   rq->elv.icq = NULL;
- }
- 
- static void blk_mq_sched_assign_ioc(struct request_queue *q,
-   struct request *rq, struct bio *bio)
- {
-   struct io_context *ioc;
- 
-   ioc = rq_ioc(bio);
-   if (ioc)
-   __blk_mq_sched_assign_ioc(q, rq, bio, ioc);
  }
  
 +/*
 + * Mark a hardware queue as needing a restart. For shared queues, maintain
 + * a count of how many hardware queues are marked for restart.
 + */
 +static void blk_mq_sched_mark_restart_hctx(struct blk_mq_hw_ctx *hctx)
 +{
 +  if (test_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  return;
 +
 +  if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
 +  struct request_queue *q = hctx->queue;
 +
 +  if (!test_and_set_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  atomic_inc(>shared_hctx_restart);
 +  } else
 +  set_bit(BLK_MQ_S_SCHED_RESTART, >state);
 +}
 +
 +static bool blk_mq_sched_restart_hctx(struct blk_mq_hw_ctx *hctx)
 +{
 +  if (!test_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  return false;
 +
 +  if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
 +  struct request_queue *q = hctx->queue;
 +
 +  if (test_and_clear_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  atomic_dec(>shared_hctx_restart);
 +  } else
 +  clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
 +
 +  if (blk_mq_hctx_has_pending(hctx)) {
 +  blk_mq_run_hw_queue(hctx, true);
 +  return true;
 +  }
 +
 +  return false;
 +}
 +
- struct request *blk_mq_sched_get_request(struct request_queue *q,
-struct bio *bio,
-unsigned int op,
-struct blk_mq_alloc_data *data)
- {
-   struct elevator_queue *e = q->elevator;
-   struct request *rq;
- 
-   blk_queue_enter_live(q);
-   data->q = q;
-   if (likely(!data->ctx))
-   data->ctx = blk_mq_get_ctx(q);
-   if (likely(!data->hctx))
-   data->hctx = blk_mq_map_queue(q, data->ctx->cpu);
- 
-   if (e) {
-   data->flags |= BLK_MQ_REQ_INTERNAL;
- 
-   /*
-* Flush requests are special and go directly to the
-* dispatch list.
-*/
-   if (!op_is_flush(op) && e->type->ops.mq.get_request) {
-   rq = e->type->ops.mq.get_request(q, op, data);
-   if (rq)
-   rq->rq_flags |= RQF_QUEUED;
-   } else
-   rq = __blk_mq_alloc_request(data, op);
-   } else {
-   rq = __blk_mq_alloc_request(data, op);
-   }
- 
-   if (rq) {
-   if (!op_is_flush(op)) {
-   rq->elv.icq = NULL;
-   if (e && e->type->icq_cache)
-   blk_mq_sched_assign_ioc(q, rq, bio);
-   }
-   data->hctx->queued++;
-   return rq;
-   }
- 
-   blk_queue_exit(q);
-   return NULL;
- }
- 
- void blk_mq_sched_put_request(struct request *rq)
- {
-   struct request_queue *q = rq->q;
-   struct elevator_queue *e = q->elevator;
- 
-   if (rq->rq_flags & RQF_ELVPRIV) {
-   blk_mq_sched_put_rq_priv(rq->q, rq);
-   if (rq->elv.icq) {
-   put_io_context(rq->elv.icq->ioc);
-   rq->elv.icq = NULL;
-   }
-   }
- 
-   if ((rq->rq_flags & RQF_QUEUED) && e && e->type->ops.mq.put_request)
-   e->type->ops.mq.put_request(rq);
-   else
-

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-mq-sched.c

between commit:

  8e8320c9315c ("blk-mq: fix performance regression with shared tags")

from Linus' tree and commits:

  d2c0d3832469 ("blk-mq: move blk_mq_sched_{get,put}_request to blk-mq.c")
  44e8c2bff80b ("blk-mq: refactor blk_mq_sched_assign_ioc")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-mq-sched.c
index 0ded5e846335,191bf82d185e..
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@@ -47,131 -46,10 +46,49 @@@ void blk_mq_sched_assign_ioc(struct req
if (!icq)
return;
}
- 
+   get_io_context(icq->ioc);
rq->elv.icq = icq;
-   if (!blk_mq_sched_get_rq_priv(q, rq, bio)) {
-   rq->rq_flags |= RQF_ELVPRIV;
-   get_io_context(icq->ioc);
-   return;
-   }
- 
-   rq->elv.icq = NULL;
- }
- 
- static void blk_mq_sched_assign_ioc(struct request_queue *q,
-   struct request *rq, struct bio *bio)
- {
-   struct io_context *ioc;
- 
-   ioc = rq_ioc(bio);
-   if (ioc)
-   __blk_mq_sched_assign_ioc(q, rq, bio, ioc);
  }
  
 +/*
 + * Mark a hardware queue as needing a restart. For shared queues, maintain
 + * a count of how many hardware queues are marked for restart.
 + */
 +static void blk_mq_sched_mark_restart_hctx(struct blk_mq_hw_ctx *hctx)
 +{
 +  if (test_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  return;
 +
 +  if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
 +  struct request_queue *q = hctx->queue;
 +
 +  if (!test_and_set_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  atomic_inc(>shared_hctx_restart);
 +  } else
 +  set_bit(BLK_MQ_S_SCHED_RESTART, >state);
 +}
 +
 +static bool blk_mq_sched_restart_hctx(struct blk_mq_hw_ctx *hctx)
 +{
 +  if (!test_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  return false;
 +
 +  if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
 +  struct request_queue *q = hctx->queue;
 +
 +  if (test_and_clear_bit(BLK_MQ_S_SCHED_RESTART, >state))
 +  atomic_dec(>shared_hctx_restart);
 +  } else
 +  clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
 +
 +  if (blk_mq_hctx_has_pending(hctx)) {
 +  blk_mq_run_hw_queue(hctx, true);
 +  return true;
 +  }
 +
 +  return false;
 +}
 +
- struct request *blk_mq_sched_get_request(struct request_queue *q,
-struct bio *bio,
-unsigned int op,
-struct blk_mq_alloc_data *data)
- {
-   struct elevator_queue *e = q->elevator;
-   struct request *rq;
- 
-   blk_queue_enter_live(q);
-   data->q = q;
-   if (likely(!data->ctx))
-   data->ctx = blk_mq_get_ctx(q);
-   if (likely(!data->hctx))
-   data->hctx = blk_mq_map_queue(q, data->ctx->cpu);
- 
-   if (e) {
-   data->flags |= BLK_MQ_REQ_INTERNAL;
- 
-   /*
-* Flush requests are special and go directly to the
-* dispatch list.
-*/
-   if (!op_is_flush(op) && e->type->ops.mq.get_request) {
-   rq = e->type->ops.mq.get_request(q, op, data);
-   if (rq)
-   rq->rq_flags |= RQF_QUEUED;
-   } else
-   rq = __blk_mq_alloc_request(data, op);
-   } else {
-   rq = __blk_mq_alloc_request(data, op);
-   }
- 
-   if (rq) {
-   if (!op_is_flush(op)) {
-   rq->elv.icq = NULL;
-   if (e && e->type->icq_cache)
-   blk_mq_sched_assign_ioc(q, rq, bio);
-   }
-   data->hctx->queued++;
-   return rq;
-   }
- 
-   blk_queue_exit(q);
-   return NULL;
- }
- 
- void blk_mq_sched_put_request(struct request *rq)
- {
-   struct request_queue *q = rq->q;
-   struct elevator_queue *e = q->elevator;
- 
-   if (rq->rq_flags & RQF_ELVPRIV) {
-   blk_mq_sched_put_rq_priv(rq->q, rq);
-   if (rq->elv.icq) {
-   put_io_context(rq->elv.icq->ioc);
-   rq->elv.icq = NULL;
-   }
-   }
- 
-   if ((rq->rq_flags & RQF_QUEUED) && e && e->type->ops.mq.put_request)
-   e->type->ops.mq.put_request(rq);
-   else
-

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-lib.c

between commit:

  05bd92dddc59 ("block: missing bio_put following submit_bio_wait")

from Linus' tree and commit:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-lib.c
index 9e29dc351695,e371f83a3186..
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@@ -103,17 -116,13 +116,14 @@@ int blkdev_issue_discard(struct block_d
struct blk_plug plug;
int ret;
  
-   if (flags & BLKDEV_DISCARD_SECURE)
-   type |= REQ_SECURE;
- 
blk_start_plug();
-   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
);
if (!ret && bio) {
-   ret = submit_bio_wait(type, bio);
-   if (ret == -EOPNOTSUPP)
+   ret = submit_bio_wait(bio);
+   if (ret == -EOPNOTSUPP && !(flags & BLKDEV_DISCARD_ZERO))
ret = 0;
 +  bio_put(bio);
}
blk_finish_plug();
  
@@@ -166,11 -176,9 +177,11 @@@ int blkdev_issue_write_same(struct bloc
}
}
  
 -  if (bio)
 +  if (bio) {
-   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
+   ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  }
-   return ret != -EOPNOTSUPP ? ret : 0;
+   return ret;
  }
  EXPORT_SYMBOL(blkdev_issue_write_same);
  
@@@ -209,11 -217,8 +220,11 @@@ static int __blkdev_issue_zeroout(struc
}
}
  
 -  if (bio)
 -  return submit_bio_wait(bio);
 +  if (bio) {
-   ret = submit_bio_wait(WRITE, bio);
++  ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  return ret;
 +  }
return 0;
  }
  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-lib.c

between commit:

  05bd92dddc59 ("block: missing bio_put following submit_bio_wait")

from Linus' tree and commit:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-lib.c
index 9e29dc351695,e371f83a3186..
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@@ -103,17 -116,13 +116,14 @@@ int blkdev_issue_discard(struct block_d
struct blk_plug plug;
int ret;
  
-   if (flags & BLKDEV_DISCARD_SECURE)
-   type |= REQ_SECURE;
- 
blk_start_plug();
-   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
);
if (!ret && bio) {
-   ret = submit_bio_wait(type, bio);
-   if (ret == -EOPNOTSUPP)
+   ret = submit_bio_wait(bio);
+   if (ret == -EOPNOTSUPP && !(flags & BLKDEV_DISCARD_ZERO))
ret = 0;
 +  bio_put(bio);
}
blk_finish_plug();
  
@@@ -166,11 -176,9 +177,11 @@@ int blkdev_issue_write_same(struct bloc
}
}
  
 -  if (bio)
 +  if (bio) {
-   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
+   ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  }
-   return ret != -EOPNOTSUPP ? ret : 0;
+   return ret;
  }
  EXPORT_SYMBOL(blkdev_issue_write_same);
  
@@@ -209,11 -217,8 +220,11 @@@ static int __blkdev_issue_zeroout(struc
}
}
  
 -  if (bio)
 -  return submit_bio_wait(bio);
 +  if (bio) {
-   ret = submit_bio_wait(WRITE, bio);
++  ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  return ret;
 +  }
return 0;
  }
  

Re: linux-next: manual merge of the block tree with Linus' tree

[Konrad Rzeszutek Wilk]

On Fri, Jul 08, 2016 at 02:14:29PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell  
> wrote:
> >
> >  +   * Get the bios in the request so we can re-queue them.
> >  +   */
> > -   if (shadow[j].request->cmd_flags &
> > -   (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
> > REQ_SECURE)) {
> > ++  if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
> > ++  req_op(shadow[j].request) == REQ_OP_DISCARD ||
> > ++  req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
> > ++  shadow[j].request->cmd_flags & REQ_FUA)) {
>   ^
> That is an extra ')' which I have now removed.

Stephen,

Thanks as always for doing this!
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Konrad Rzeszutek Wilk]

On Fri, Jul 08, 2016 at 02:14:29PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell  
> wrote:
> >
> >  +   * Get the bios in the request so we can re-queue them.
> >  +   */
> > -   if (shadow[j].request->cmd_flags &
> > -   (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
> > REQ_SECURE)) {
> > ++  if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
> > ++  req_op(shadow[j].request) == REQ_OP_DISCARD ||
> > ++  req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
> > ++  shadow[j].request->cmd_flags & REQ_FUA)) {
>   ^
> That is an extra ')' which I have now removed.

Stephen,

Thanks as always for doing this!
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell  
wrote:
>
>  + * Get the bios in the request so we can re-queue them.
>  + */
> - if (shadow[j].request->cmd_flags &
> - (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
> REQ_SECURE)) {
> ++if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
> ++req_op(shadow[j].request) == REQ_OP_DISCARD ||
> ++req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
> ++shadow[j].request->cmd_flags & REQ_FUA)) {
  ^
That is an extra ')' which I have now removed.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell  
wrote:
>
>  + * Get the bios in the request so we can re-queue them.
>  + */
> - if (shadow[j].request->cmd_flags &
> - (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
> REQ_SECURE)) {
> ++if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
> ++req_op(shadow[j].request) == REQ_OP_DISCARD ||
> ++req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
> ++shadow[j].request->cmd_flags & REQ_FUA)) {
  ^
That is an extra ')' which I have now removed.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/block/xen-blkfront.c

between commit:

  7b427a59538a ("xen-blkfront: save uncompleted reqs in blkfront_resume()")

from Linus' tree and commit:

  c2df40dfb8c0 ("drivers: use req op accessor")
  3a5e02ced11e ("block, drivers: add REQ_OP_FLUSH operation")
  288dab8a35a0 ("block: add a separate operation type for secure erase")

from the block tree.

I fixed it up (I *think* - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/block/xen-blkfront.c
index fcc5b4e0aef2,10711292da2c..
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@@ -2093,38 -2143,6 +2089,43 @@@ static int blkfront_resume(struct xenbu
  
dev_dbg(>dev, "blkfront_resume: %s\n", dev->nodename);
  
 +  bio_list_init(>bio_list);
 +  INIT_LIST_HEAD(>requests);
 +  for (i = 0; i < info->nr_rings; i++) {
 +  struct blkfront_ring_info *rinfo = >rinfo[i];
 +  struct bio_list merge_bio;
 +  struct blk_shadow *shadow = rinfo->shadow;
 +
 +  for (j = 0; j < BLK_RING_SIZE(info); j++) {
 +  /* Not in use? */
 +  if (!shadow[j].request)
 +  continue;
 +
 +  /*
 +   * Get the bios in the request so we can re-queue them.
 +   */
-   if (shadow[j].request->cmd_flags &
-   (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
REQ_SECURE)) {
++  if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
++  req_op(shadow[j].request) == REQ_OP_DISCARD ||
++  req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
++  shadow[j].request->cmd_flags & REQ_FUA)) {
 +  /*
 +   * Flush operations don't contain bios, so
 +   * we need to requeue the whole request
++   *
++   * XXX: but this doesn't make any sense for a
++   * write with the FUA flag set..
 +   */
 +  list_add([j].request->queuelist, 
>requests);
 +  continue;
 +  }
 +  merge_bio.head = shadow[j].request->bio;
 +  merge_bio.tail = shadow[j].request->biotail;
 +  bio_list_merge(>bio_list, _bio);
 +  shadow[j].request->bio = NULL;
 +  blk_mq_end_request(shadow[j].request, 0);
 +  }
 +  }
 +
blkif_free(info, info->connected == BLKIF_STATE_CONNECTED);
  
err = negotiate_mq(info);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/block/xen-blkfront.c

between commit:

  7b427a59538a ("xen-blkfront: save uncompleted reqs in blkfront_resume()")

from Linus' tree and commit:

  c2df40dfb8c0 ("drivers: use req op accessor")
  3a5e02ced11e ("block, drivers: add REQ_OP_FLUSH operation")
  288dab8a35a0 ("block: add a separate operation type for secure erase")

from the block tree.

I fixed it up (I *think* - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/block/xen-blkfront.c
index fcc5b4e0aef2,10711292da2c..
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@@ -2093,38 -2143,6 +2089,43 @@@ static int blkfront_resume(struct xenbu
  
dev_dbg(>dev, "blkfront_resume: %s\n", dev->nodename);
  
 +  bio_list_init(>bio_list);
 +  INIT_LIST_HEAD(>requests);
 +  for (i = 0; i < info->nr_rings; i++) {
 +  struct blkfront_ring_info *rinfo = >rinfo[i];
 +  struct bio_list merge_bio;
 +  struct blk_shadow *shadow = rinfo->shadow;
 +
 +  for (j = 0; j < BLK_RING_SIZE(info); j++) {
 +  /* Not in use? */
 +  if (!shadow[j].request)
 +  continue;
 +
 +  /*
 +   * Get the bios in the request so we can re-queue them.
 +   */
-   if (shadow[j].request->cmd_flags &
-   (REQ_FLUSH | REQ_FUA | REQ_DISCARD | 
REQ_SECURE)) {
++  if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
++  req_op(shadow[j].request) == REQ_OP_DISCARD ||
++  req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
++  shadow[j].request->cmd_flags & REQ_FUA)) {
 +  /*
 +   * Flush operations don't contain bios, so
 +   * we need to requeue the whole request
++   *
++   * XXX: but this doesn't make any sense for a
++   * write with the FUA flag set..
 +   */
 +  list_add([j].request->queuelist, 
>requests);
 +  continue;
 +  }
 +  merge_bio.head = shadow[j].request->bio;
 +  merge_bio.tail = shadow[j].request->biotail;
 +  bio_list_merge(>bio_list, _bio);
 +  shadow[j].request->bio = NULL;
 +  blk_mq_end_request(shadow[j].request, 0);
 +  }
 +  }
 +
blkif_free(info, info->connected == BLKIF_STATE_CONNECTED);
  
err = negotiate_mq(info);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-lib.c

between commit:

  05bd92dddc59 ("block: missing bio_put following submit_bio_wait")

from the FIXME tree and commit:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-lib.c
index 9e29dc351695,78626c2fde33..
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@@ -103,17 -111,13 +111,14 @@@ int blkdev_issue_discard(struct block_d
struct blk_plug plug;
int ret;
  
-   if (flags & BLKDEV_DISCARD_SECURE)
-   type |= REQ_SECURE;
- 
blk_start_plug();
-   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
);
if (!ret && bio) {
-   ret = submit_bio_wait(type, bio);
+   ret = submit_bio_wait(bio);
if (ret == -EOPNOTSUPP)
ret = 0;
 +  bio_put(bio);
}
blk_finish_plug();
  
@@@ -166,10 -171,8 +172,10 @@@ int blkdev_issue_write_same(struct bloc
}
}
  
 -  if (bio)
 +  if (bio) {
-   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
+   ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  }
return ret != -EOPNOTSUPP ? ret : 0;
  }
  EXPORT_SYMBOL(blkdev_issue_write_same);
@@@ -209,11 -212,8 +215,11 @@@ static int __blkdev_issue_zeroout(struc
}
}
  
 -  if (bio)
 -  return submit_bio_wait(bio);
 +  if (bio) {
-   ret = submit_bio_wait(WRITE, bio);
++  ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  return ret;
 +  }
return 0;
  }
  

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  block/blk-lib.c

between commit:

  05bd92dddc59 ("block: missing bio_put following submit_bio_wait")

from the FIXME tree and commit:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc block/blk-lib.c
index 9e29dc351695,78626c2fde33..
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@@ -103,17 -111,13 +111,14 @@@ int blkdev_issue_discard(struct block_d
struct blk_plug plug;
int ret;
  
-   if (flags & BLKDEV_DISCARD_SECURE)
-   type |= REQ_SECURE;
- 
blk_start_plug();
-   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+   ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
);
if (!ret && bio) {
-   ret = submit_bio_wait(type, bio);
+   ret = submit_bio_wait(bio);
if (ret == -EOPNOTSUPP)
ret = 0;
 +  bio_put(bio);
}
blk_finish_plug();
  
@@@ -166,10 -171,8 +172,10 @@@ int blkdev_issue_write_same(struct bloc
}
}
  
 -  if (bio)
 +  if (bio) {
-   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
+   ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  }
return ret != -EOPNOTSUPP ? ret : 0;
  }
  EXPORT_SYMBOL(blkdev_issue_write_same);
@@@ -209,11 -212,8 +215,11 @@@ static int __blkdev_issue_zeroout(struc
}
}
  
 -  if (bio)
 -  return submit_bio_wait(bio);
 +  if (bio) {
-   ret = submit_bio_wait(WRITE, bio);
++  ret = submit_bio_wait(bio);
 +  bio_put(bio);
 +  return ret;
 +  }
return 0;
  }
  

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 05/02/2016 10:25 PM, Stephen Rothwell wrote:

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

   drivers/nvme/host/pci.c

between commit:

   9bf2b972afea ("NVMe: Fix reset/remove race")

from Linus' tree and commit:

   bb8d261e0888 ("nvme: introduce a controller state machine")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.


There's a proper fixup in my for-next now, so you should be able to drop 
this one.


--
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 05/02/2016 10:25 PM, Stephen Rothwell wrote:

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

   drivers/nvme/host/pci.c

between commit:

   9bf2b972afea ("NVMe: Fix reset/remove race")

from Linus' tree and commit:

   bb8d261e0888 ("nvme: introduce a controller state machine")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.


There's a proper fixup in my for-next now, so you should be able to drop 
this one.


--
Jens Axboe

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  9bf2b972afea ("NVMe: Fix reset/remove race")

from Linus' tree and commit:

  bb8d261e0888 ("nvme: introduce a controller state machine")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index 4fd733ff72b1,077e9bf6a1b8..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1864,10 -1789,8 +1789,11 @@@ static void nvme_reset_work(struct work
if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
nvme_dev_disable(dev, false);
  
-   if (test_bit(NVME_CTRL_REMOVING, >flags))
++  if (dev->ctrl.state != NVME_CTRL_DELETING)
 +  goto out;
 +
-   set_bit(NVME_CTRL_RESETTING, >flags);
+   if (!nvme_change_ctrl_state(>ctrl, NVME_CTRL_RESETTING))
+   goto out;
  
result = nvme_pci_enable(dev);
if (result)
@@@ -2086,12 -2014,11 +2017,10 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
-   set_bit(NVME_CTRL_REMOVING, >flags);
 -  del_timer_sync(>watchdog_timer);
 -
+   nvme_change_ctrl_state(>ctrl, NVME_CTRL_DELETING);
+ 
pci_set_drvdata(pdev, NULL);
-   flush_work(>async_work);
 +  flush_work(>reset_work);
-   flush_work(>scan_work);
-   nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);
nvme_dev_disable(dev, true);
flush_work(>reset_work);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  9bf2b972afea ("NVMe: Fix reset/remove race")

from Linus' tree and commit:

  bb8d261e0888 ("nvme: introduce a controller state machine")

from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index 4fd733ff72b1,077e9bf6a1b8..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1864,10 -1789,8 +1789,11 @@@ static void nvme_reset_work(struct work
if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
nvme_dev_disable(dev, false);
  
-   if (test_bit(NVME_CTRL_REMOVING, >flags))
++  if (dev->ctrl.state != NVME_CTRL_DELETING)
 +  goto out;
 +
-   set_bit(NVME_CTRL_RESETTING, >flags);
+   if (!nvme_change_ctrl_state(>ctrl, NVME_CTRL_RESETTING))
+   goto out;
  
result = nvme_pci_enable(dev);
if (result)
@@@ -2086,12 -2014,11 +2017,10 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
-   set_bit(NVME_CTRL_REMOVING, >flags);
 -  del_timer_sync(>watchdog_timer);
 -
+   nvme_change_ctrl_state(>ctrl, NVME_CTRL_DELETING);
+ 
pci_set_drvdata(pdev, NULL);
-   flush_work(>async_work);
 +  flush_work(>reset_work);
-   flush_work(>scan_work);
-   nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);
nvme_dev_disable(dev, true);
flush_work(>reset_work);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/core.c

between commit:

  075790ebba4a ("NVMe: Use IDA for namespace disk naming")

from Linus' tree and commit:

  f4f0f63e6f01 ("nvme: fix drvdata setup for the nvme device")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/core.c
index 03c46412fff4,f08dccee8143..
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@@ -561,13 -598,9 +603,13 @@@ static int nvme_revalidate_disk(struct 
u16 old_ms;
unsigned short bs;
  
 +  if (test_bit(NVME_NS_DEAD, >flags)) {
 +  set_capacity(disk, 0);
 +  return -ENODEV;
 +  }
if (nvme_identify_ns(ns->ctrl, ns->ns_id, )) {
-   dev_warn(ns->ctrl->dev, "%s: Identify failure nvme%dn%d\n",
-   __func__, ns->ctrl->instance, ns->ns_id);
+   dev_warn(disk_to_dev(ns->disk), "%s: Identify failure\n",
+   __func__);
return -ENODEV;
}
if (id->ncap == 0) {
@@@ -839,24 -874,8 +883,25 @@@ int nvme_shutdown_ctrl(struct nvme_ctr
  
return ret;
  }
+ EXPORT_SYMBOL_GPL(nvme_shutdown_ctrl);
  
 +static void nvme_set_queue_limits(struct nvme_ctrl *ctrl,
 +  struct request_queue *q)
 +{
 +  if (ctrl->max_hw_sectors) {
 +  u32 max_segments =
 +  (ctrl->max_hw_sectors / (ctrl->page_size >> 9)) + 1;
 +
 +  blk_queue_max_hw_sectors(q, ctrl->max_hw_sectors);
 +  blk_queue_max_segments(q, min_t(u32, max_segments, USHRT_MAX));
 +  }
 +  if (ctrl->stripe_size)
 +  blk_queue_chunk_sectors(q, ctrl->stripe_size >> 9);
 +  if (ctrl->vwc & NVME_CTRL_VWC_PRESENT)
 +  blk_queue_flush(q, REQ_FLUSH | REQ_FUA);
 +  blk_queue_virt_boundary(q, ctrl->page_size - 1);
 +}
 +
  /*
   * Initialize the cached copies of the Identify data and various controller
   * register in our nvme_ctrl structure.  This should be called as soon as
@@@ -1313,9 -1360,12 +1372,10 @@@ void nvme_remove_namespaces(struct nvme
  {
struct nvme_ns *ns, *next;
  
 -  mutex_lock(>namespaces_mutex);
list_for_each_entry_safe(ns, next, >namespaces, list)
nvme_ns_remove(ns);
 -  mutex_unlock(>namespaces_mutex);
  }
+ EXPORT_SYMBOL_GPL(nvme_remove_namespaces);
  
  static DEFINE_IDA(nvme_instance_ida);
  
@@@ -1401,8 -1452,6 +1463,7 @@@ int nvme_init_ctrl(struct nvme_ctrl *ct
goto out_release_instance;
}
get_device(ctrl->device);
-   dev_set_drvdata(ctrl->device, ctrl);
 +  ida_init(>ns_ida);
  
spin_lock(_list_lock);
list_add_tail(>node, _ctrl_list);
@@@ -1414,39 -1463,8 +1475,40 @@@ out_release_instance
  out:
return ret;
  }
+ EXPORT_SYMBOL_GPL(nvme_init_ctrl);
  
 +/**
 + * nvme_kill_queues(): Ends all namespace queues
 + * @ctrl: the dead controller that needs to end
 + *
 + * Call this function when the driver determines it is unable to get the
 + * controller in a state capable of servicing IO.
 + */
 +void nvme_kill_queues(struct nvme_ctrl *ctrl)
 +{
 +  struct nvme_ns *ns;
 +
 +  mutex_lock(>namespaces_mutex);
 +  list_for_each_entry(ns, >namespaces, list) {
 +  if (!kref_get_unless_zero(>kref))
 +  continue;
 +
 +  /*
 +   * Revalidating a dead namespace sets capacity to 0. This will
 +   * end buffered writers dirtying pages that can't be synced.
 +   */
 +  if (!test_and_set_bit(NVME_NS_DEAD, >flags))
 +  revalidate_disk(ns->disk);
 +
 +  blk_set_queue_dying(ns->queue);
 +  blk_mq_abort_requeue_list(ns->queue);
 +  blk_mq_start_stopped_hw_queues(ns->queue, true);
 +
 +  nvme_put_ns(ns);
 +  }
 +  mutex_unlock(>namespaces_mutex);
 +}
 +
  void nvme_stop_queues(struct nvme_ctrl *ctrl)
  {
struct nvme_ns *ns;

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/core.c

between commit:

  075790ebba4a ("NVMe: Use IDA for namespace disk naming")

from Linus' tree and commit:

  f4f0f63e6f01 ("nvme: fix drvdata setup for the nvme device")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/core.c
index 03c46412fff4,f08dccee8143..
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@@ -561,13 -598,9 +603,13 @@@ static int nvme_revalidate_disk(struct 
u16 old_ms;
unsigned short bs;
  
 +  if (test_bit(NVME_NS_DEAD, >flags)) {
 +  set_capacity(disk, 0);
 +  return -ENODEV;
 +  }
if (nvme_identify_ns(ns->ctrl, ns->ns_id, )) {
-   dev_warn(ns->ctrl->dev, "%s: Identify failure nvme%dn%d\n",
-   __func__, ns->ctrl->instance, ns->ns_id);
+   dev_warn(disk_to_dev(ns->disk), "%s: Identify failure\n",
+   __func__);
return -ENODEV;
}
if (id->ncap == 0) {
@@@ -839,24 -874,8 +883,25 @@@ int nvme_shutdown_ctrl(struct nvme_ctr
  
return ret;
  }
+ EXPORT_SYMBOL_GPL(nvme_shutdown_ctrl);
  
 +static void nvme_set_queue_limits(struct nvme_ctrl *ctrl,
 +  struct request_queue *q)
 +{
 +  if (ctrl->max_hw_sectors) {
 +  u32 max_segments =
 +  (ctrl->max_hw_sectors / (ctrl->page_size >> 9)) + 1;
 +
 +  blk_queue_max_hw_sectors(q, ctrl->max_hw_sectors);
 +  blk_queue_max_segments(q, min_t(u32, max_segments, USHRT_MAX));
 +  }
 +  if (ctrl->stripe_size)
 +  blk_queue_chunk_sectors(q, ctrl->stripe_size >> 9);
 +  if (ctrl->vwc & NVME_CTRL_VWC_PRESENT)
 +  blk_queue_flush(q, REQ_FLUSH | REQ_FUA);
 +  blk_queue_virt_boundary(q, ctrl->page_size - 1);
 +}
 +
  /*
   * Initialize the cached copies of the Identify data and various controller
   * register in our nvme_ctrl structure.  This should be called as soon as
@@@ -1313,9 -1360,12 +1372,10 @@@ void nvme_remove_namespaces(struct nvme
  {
struct nvme_ns *ns, *next;
  
 -  mutex_lock(>namespaces_mutex);
list_for_each_entry_safe(ns, next, >namespaces, list)
nvme_ns_remove(ns);
 -  mutex_unlock(>namespaces_mutex);
  }
+ EXPORT_SYMBOL_GPL(nvme_remove_namespaces);
  
  static DEFINE_IDA(nvme_instance_ida);
  
@@@ -1401,8 -1452,6 +1463,7 @@@ int nvme_init_ctrl(struct nvme_ctrl *ct
goto out_release_instance;
}
get_device(ctrl->device);
-   dev_set_drvdata(ctrl->device, ctrl);
 +  ida_init(>ns_ida);
  
spin_lock(_list_lock);
list_add_tail(>node, _ctrl_list);
@@@ -1414,39 -1463,8 +1475,40 @@@ out_release_instance
  out:
return ret;
  }
+ EXPORT_SYMBOL_GPL(nvme_init_ctrl);
  
 +/**
 + * nvme_kill_queues(): Ends all namespace queues
 + * @ctrl: the dead controller that needs to end
 + *
 + * Call this function when the driver determines it is unable to get the
 + * controller in a state capable of servicing IO.
 + */
 +void nvme_kill_queues(struct nvme_ctrl *ctrl)
 +{
 +  struct nvme_ns *ns;
 +
 +  mutex_lock(>namespaces_mutex);
 +  list_for_each_entry(ns, >namespaces, list) {
 +  if (!kref_get_unless_zero(>kref))
 +  continue;
 +
 +  /*
 +   * Revalidating a dead namespace sets capacity to 0. This will
 +   * end buffered writers dirtying pages that can't be synced.
 +   */
 +  if (!test_and_set_bit(NVME_NS_DEAD, >flags))
 +  revalidate_disk(ns->disk);
 +
 +  blk_set_queue_dying(ns->queue);
 +  blk_mq_abort_requeue_list(ns->queue);
 +  blk_mq_start_stopped_hw_queues(ns->queue, true);
 +
 +  nvme_put_ns(ns);
 +  }
 +  mutex_unlock(>namespaces_mutex);
 +}
 +
  void nvme_stop_queues(struct nvme_ctrl *ctrl)
  {
struct nvme_ns *ns;

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  ff23a2a15a21 ("NVMe: Poll device while still active during remove")
  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")
  b00a726a9fd8 ("NVMe: Don't unmap controller registers on reset")
  646017a612e7 ("NVMe: Fix namespace removal deadlock")
  f58944e265d4 ("NVMe: Simplify device reset failure")

from Linus' tree and commit:

  949928c1c731 ("NVMe: Fix possible queue use after freed")
  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")
  9396dec916c0 ("nvme: use a work item to submit async event requests")
  2d55cd5f511d ("nvme: replace the kthread with a per-device watchdog timer")

from the block tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index 680f5780750c,d47b08783110..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -310,10 -288,10 +299,10 @@@ static void nvme_complete_async_event(s
  
switch (result & 0xff07) {
case NVME_AER_NOTICE_NS_CHANGED:
-   dev_info(dev->dev, "rescanning\n");
+   dev_info(dev->ctrl.device, "rescanning\n");
 -  queue_work(nvme_workq, >scan_work);
 +  nvme_queue_scan(dev);
default:
-   dev_warn(dev->dev, "async event result %08x\n", result);
+   dev_warn(dev->ctrl.device, "async event result %08x\n", result);
}
  }
  
@@@ -1018,7 -992,7 +1011,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;
@@@ -1709,8 -1651,14 +1676,14 @@@ static int nvme_dev_add(struct nvme_de
if (blk_mq_alloc_tag_set(>tagset))
return 0;
dev->ctrl.tagset = >tagset;
+   } else {
+   blk_mq_update_nr_hw_queues(>tagset, dev->online_queues - 
1);
+ 
+   /* Free previously allocated queues that are no longer usable */
+   nvme_free_queues(dev, dev->online_queues);
}
+ 
 -  queue_work(nvme_workq, >scan_work);
 +  nvme_queue_scan(dev);
return 0;
  }
  
@@@ -1845,10 -1763,10 +1774,10 @@@ static void nvme_dev_disable(struct nvm
int i;
u32 csts = -1;
  
-   nvme_dev_list_remove(dev);
+   del_timer_sync(>watchdog_timer);
  
mutex_lock(>shutdown_lock);
 -  if (dev->bar) {
 +  if (pci_is_enabled(to_pci_dev(dev->dev))) {
nvme_stop_queues(>ctrl);
csts = readl(dev->bar + NVME_REG_CSTS);
}
@@@ -1951,13 -1859,12 +1880,12 @@@ static void nvme_reset_work(struct work
  
result = nvme_setup_io_queues(dev);
if (result)
 -  goto free_tags;
 +  goto out;
  
dev->ctrl.event_limit = NVME_NR_AEN_COMMANDS;
+   queue_work(nvme_workq, >async_work);
  
-   result = nvme_dev_list_add(dev);
-   if (result)
-   goto out;
+   mod_timer(>watchdog_timer, round_jiffies(jiffies + HZ));
  
/*
 * Keep the controller around but remove all namespaces if we don't have
@@@ -2085,11 -1988,6 +2014,10 @@@ static int nvme_probe(struct pci_dev *p
dev->dev = get_device(>dev);
pci_set_drvdata(pdev, dev);
  
 +  result = nvme_dev_map(dev);
 +  if (result)
 +  goto free;
 +
-   INIT_LIST_HEAD(>node);
INIT_WORK(>scan_work, nvme_dev_scan);
INIT_WORK(>reset_work, nvme_reset_work);
INIT_WORK(>remove_work, nvme_remove_dead_ctrl_work);
@@@ -2145,8 -2042,11 +2078,11 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
 +  set_bit(NVME_CTRL_REMOVING, >flags);
+   del_timer_sync(>watchdog_timer);
+ 
pci_set_drvdata(pdev, NULL);
+   flush_work(>async_work);
 -  flush_work(>reset_work);
flush_work(>scan_work);
nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  ff23a2a15a21 ("NVMe: Poll device while still active during remove")
  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")
  b00a726a9fd8 ("NVMe: Don't unmap controller registers on reset")
  646017a612e7 ("NVMe: Fix namespace removal deadlock")
  f58944e265d4 ("NVMe: Simplify device reset failure")

from Linus' tree and commit:

  949928c1c731 ("NVMe: Fix possible queue use after freed")
  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")
  9396dec916c0 ("nvme: use a work item to submit async event requests")
  2d55cd5f511d ("nvme: replace the kthread with a per-device watchdog timer")

from the block tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index 680f5780750c,d47b08783110..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -310,10 -288,10 +299,10 @@@ static void nvme_complete_async_event(s
  
switch (result & 0xff07) {
case NVME_AER_NOTICE_NS_CHANGED:
-   dev_info(dev->dev, "rescanning\n");
+   dev_info(dev->ctrl.device, "rescanning\n");
 -  queue_work(nvme_workq, >scan_work);
 +  nvme_queue_scan(dev);
default:
-   dev_warn(dev->dev, "async event result %08x\n", result);
+   dev_warn(dev->ctrl.device, "async event result %08x\n", result);
}
  }
  
@@@ -1018,7 -992,7 +1011,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;
@@@ -1709,8 -1651,14 +1676,14 @@@ static int nvme_dev_add(struct nvme_de
if (blk_mq_alloc_tag_set(>tagset))
return 0;
dev->ctrl.tagset = >tagset;
+   } else {
+   blk_mq_update_nr_hw_queues(>tagset, dev->online_queues - 
1);
+ 
+   /* Free previously allocated queues that are no longer usable */
+   nvme_free_queues(dev, dev->online_queues);
}
+ 
 -  queue_work(nvme_workq, >scan_work);
 +  nvme_queue_scan(dev);
return 0;
  }
  
@@@ -1845,10 -1763,10 +1774,10 @@@ static void nvme_dev_disable(struct nvm
int i;
u32 csts = -1;
  
-   nvme_dev_list_remove(dev);
+   del_timer_sync(>watchdog_timer);
  
mutex_lock(>shutdown_lock);
 -  if (dev->bar) {
 +  if (pci_is_enabled(to_pci_dev(dev->dev))) {
nvme_stop_queues(>ctrl);
csts = readl(dev->bar + NVME_REG_CSTS);
}
@@@ -1951,13 -1859,12 +1880,12 @@@ static void nvme_reset_work(struct work
  
result = nvme_setup_io_queues(dev);
if (result)
 -  goto free_tags;
 +  goto out;
  
dev->ctrl.event_limit = NVME_NR_AEN_COMMANDS;
+   queue_work(nvme_workq, >async_work);
  
-   result = nvme_dev_list_add(dev);
-   if (result)
-   goto out;
+   mod_timer(>watchdog_timer, round_jiffies(jiffies + HZ));
  
/*
 * Keep the controller around but remove all namespaces if we don't have
@@@ -2085,11 -1988,6 +2014,10 @@@ static int nvme_probe(struct pci_dev *p
dev->dev = get_device(>dev);
pci_set_drvdata(pdev, dev);
  
 +  result = nvme_dev_map(dev);
 +  if (result)
 +  goto free;
 +
-   INIT_LIST_HEAD(>node);
INIT_WORK(>scan_work, nvme_dev_scan);
INIT_WORK(>reset_work, nvme_reset_work);
INIT_WORK(>remove_work, nvme_remove_dead_ctrl_work);
@@@ -2145,8 -2042,11 +2078,11 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
 +  set_bit(NVME_CTRL_REMOVING, >flags);
+   del_timer_sync(>watchdog_timer);
+ 
pci_set_drvdata(pdev, NULL);
+   flush_work(>async_work);
 -  flush_work(>reset_work);
flush_work(>scan_work);
nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commits:

  7ba7735d039c ("NVMe: Poll device while still active during remove")
  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")

from Linus' tree and commit:

  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")
  9396dec916c0 ("nvme: use a work item to submit async event requests")
  2d55cd5f511d ("nvme: replace the kthread with a per-device watchdog timer")

from the block tree.

I fixed it up (maybe - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index a128672472ec,d47b08783110..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1004,7 -992,7 +997,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;
@@@ -2116,7 -2042,11 +2047,10 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
+   del_timer_sync(>watchdog_timer);
+ 
pci_set_drvdata(pdev, NULL);
+   flush_work(>async_work);
 -  flush_work(>reset_work);
flush_work(>scan_work);
nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commits:

  7ba7735d039c ("NVMe: Poll device while still active during remove")
  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")

from Linus' tree and commit:

  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")
  9396dec916c0 ("nvme: use a work item to submit async event requests")
  2d55cd5f511d ("nvme: replace the kthread with a per-device watchdog timer")

from the block tree.

I fixed it up (maybe - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index a128672472ec,d47b08783110..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1004,7 -992,7 +997,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;
@@@ -2116,7 -2042,11 +2047,10 @@@ static void nvme_remove(struct pci_dev 
  {
struct nvme_dev *dev = pci_get_drvdata(pdev);
  
+   del_timer_sync(>watchdog_timer);
+ 
pci_set_drvdata(pdev, NULL);
+   flush_work(>async_work);
 -  flush_work(>reset_work);
flush_work(>scan_work);
nvme_remove_namespaces(>ctrl);
nvme_uninit_ctrl(>ctrl);

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")

from Linus' tree and commit:

  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index a128672472ec,fec747917690..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1004,7 -990,7 +995,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  f8e68a7c9af5 ("NVMe: Rate limit nvme IO warnings")

from Linus' tree and commit:

  1b3c47c182aa ("nvme: Log the ctrl device name instead of the underlying pci 
device name")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/nvme/host/pci.c
index a128672472ec,fec747917690..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -1004,7 -990,7 +995,7 @@@ static void nvme_cancel_queue_ios(struc
if (!blk_mq_request_started(req))
return;
  
-   dev_dbg_ratelimited(nvmeq->q_dmadev,
 -  dev_warn(nvmeq->dev->ctrl.device,
++  dev_dbg_ratelimited(nvmeq->dev->ctrl.device,
 "Cancelling I/O %d QID %d\n", req->tag, nvmeq->qid);
  
status = NVME_SC_ABORT_REQ;

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 01/21/2016 03:46 PM, Stephen Rothwell wrote:

Hi Jens,

On Thu, 31 Dec 2015 14:34:57 +1100 Stephen Rothwell  
wrote:


Today's linux-next merge of the block tree got a conflict in:

   drivers/nvme/host/pci.c

between commit:

   b5875222de2f ("NVMe: IO ending fixes on surprise removal")

from Linus' tree and commit:

   5bae7f73d378 ("nvme: move namespace scanning to common code")

from the block tree.

I fixed it up (the code was moved - I added the fix patch below) and
can carry the fix as necessary (no action is required).

However, there was another part to the former patch that I could not
quite figure out how to reproduce - the fix to nvme_dev_remove().

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 14:21:38 +1100
Subject: [PATCH] nvme: merge fix up for ns code movement

Signed-off-by: Stephen Rothwell 
---
  drivers/nvme/host/core.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1437ff36e91c..1375a83593b5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
bool kill = nvme_io_incapable(ns->ctrl) &&
!blk_queue_dying(ns->queue);

-   if (kill)
+   if (kill) {
blk_set_queue_dying(ns->queue);
+
+   /*
+* The controller was shutdown first if we got here through
+* device removal. The shutdown may requeue outstanding
+* requests. These need to be aborted immediately so
+* del_gendisk doesn't block indefinitely for their completion.
+*/
+   blk_mq_abort_requeue_list(ns->queue);
+   }
if (ns->disk->flags & GENHD_FL_UP) {
if (blk_get_integrity(ns->disk))
blk_integrity_unregister(ns->disk);
--
2.6.4


So, I have been applying the above merge fix patch since Dec 31 and now
wonder if Linus needs to be told about it.  Also noone every replied
about the nvme_dev_remove() part.


Linus is usually pretty damn good at figuring out, and seems to have fun 
doing it. So I usually just defer to acking a merge resolution, but even 
that is rarely needed. It was more of a mess this time around between 
mainline and the nvme branch than I would have liked though, but mostly 
due to timing of branching.



--
Jens Axboe

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 31 Dec 2015 14:34:57 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/nvme/host/pci.c
> 
> between commit:
> 
>   b5875222de2f ("NVMe: IO ending fixes on surprise removal")
> 
> from Linus' tree and commit:
> 
>   5bae7f73d378 ("nvme: move namespace scanning to common code")
> 
> from the block tree.
> 
> I fixed it up (the code was moved - I added the fix patch below) and
> can carry the fix as necessary (no action is required).
> 
> However, there was another part to the former patch that I could not
> quite figure out how to reproduce - the fix to nvme_dev_remove().
> 
> From: Stephen Rothwell 
> Date: Thu, 31 Dec 2015 14:21:38 +1100
> Subject: [PATCH] nvme: merge fix up for ns code movement
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/nvme/host/core.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 1437ff36e91c..1375a83593b5 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
>   bool kill = nvme_io_incapable(ns->ctrl) &&
>   !blk_queue_dying(ns->queue);
>  
> - if (kill)
> + if (kill) {
>   blk_set_queue_dying(ns->queue);
> +
> + /*
> +  * The controller was shutdown first if we got here through
> +  * device removal. The shutdown may requeue outstanding
> +  * requests. These need to be aborted immediately so
> +  * del_gendisk doesn't block indefinitely for their completion.
> +  */
> + blk_mq_abort_requeue_list(ns->queue);
> + }
>   if (ns->disk->flags & GENHD_FL_UP) {
>   if (blk_get_integrity(ns->disk))
>   blk_integrity_unregister(ns->disk);
> -- 
> 2.6.4

So, I have been applying the above merge fix patch since Dec 31 and now
wonder if Linus needs to be told about it.  Also noone every replied
about the nvme_dev_remove() part.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

Re: linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

On Thu, 31 Dec 2015 14:34:57 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/nvme/host/pci.c
> 
> between commit:
> 
>   b5875222de2f ("NVMe: IO ending fixes on surprise removal")
> 
> from Linus' tree and commit:
> 
>   5bae7f73d378 ("nvme: move namespace scanning to common code")
> 
> from the block tree.
> 
> I fixed it up (the code was moved - I added the fix patch below) and
> can carry the fix as necessary (no action is required).
> 
> However, there was another part to the former patch that I could not
> quite figure out how to reproduce - the fix to nvme_dev_remove().
> 
> From: Stephen Rothwell 
> Date: Thu, 31 Dec 2015 14:21:38 +1100
> Subject: [PATCH] nvme: merge fix up for ns code movement
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/nvme/host/core.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 1437ff36e91c..1375a83593b5 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
>   bool kill = nvme_io_incapable(ns->ctrl) &&
>   !blk_queue_dying(ns->queue);
>  
> - if (kill)
> + if (kill) {
>   blk_set_queue_dying(ns->queue);
> +
> + /*
> +  * The controller was shutdown first if we got here through
> +  * device removal. The shutdown may requeue outstanding
> +  * requests. These need to be aborted immediately so
> +  * del_gendisk doesn't block indefinitely for their completion.
> +  */
> + blk_mq_abort_requeue_list(ns->queue);
> + }
>   if (ns->disk->flags & GENHD_FL_UP) {
>   if (blk_get_integrity(ns->disk))
>   blk_integrity_unregister(ns->disk);
> -- 
> 2.6.4

So, I have been applying the above merge fix patch since Dec 31 and now
wonder if Linus needs to be told about it.  Also noone every replied
about the nvme_dev_remove() part.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

Re: linux-next: manual merge of the block tree with Linus' tree

[Jens Axboe]

On 01/21/2016 03:46 PM, Stephen Rothwell wrote:

Hi Jens,

On Thu, 31 Dec 2015 14:34:57 +1100 Stephen Rothwell  
wrote:


Today's linux-next merge of the block tree got a conflict in:

   drivers/nvme/host/pci.c

between commit:

   b5875222de2f ("NVMe: IO ending fixes on surprise removal")

from Linus' tree and commit:

   5bae7f73d378 ("nvme: move namespace scanning to common code")

from the block tree.

I fixed it up (the code was moved - I added the fix patch below) and
can carry the fix as necessary (no action is required).

However, there was another part to the former patch that I could not
quite figure out how to reproduce - the fix to nvme_dev_remove().

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 14:21:38 +1100
Subject: [PATCH] nvme: merge fix up for ns code movement

Signed-off-by: Stephen Rothwell 
---
  drivers/nvme/host/core.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1437ff36e91c..1375a83593b5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
bool kill = nvme_io_incapable(ns->ctrl) &&
!blk_queue_dying(ns->queue);

-   if (kill)
+   if (kill) {
blk_set_queue_dying(ns->queue);
+
+   /*
+* The controller was shutdown first if we got here through
+* device removal. The shutdown may requeue outstanding
+* requests. These need to be aborted immediately so
+* del_gendisk doesn't block indefinitely for their completion.
+*/
+   blk_mq_abort_requeue_list(ns->queue);
+   }
if (ns->disk->flags & GENHD_FL_UP) {
if (blk_get_integrity(ns->disk))
blk_integrity_unregister(ns->disk);
--
2.6.4


So, I have been applying the above merge fix patch since Dec 31 and now
wonder if Linus needs to be told about it.  Also noone every replied
about the nvme_dev_remove() part.


Linus is usually pretty damn good at figuring out, and seems to have fun 
doing it. So I usually just defer to acking a merge resolution, but even 
that is rarely needed. It was more of a mess this time around between 
mainline and the nvme branch than I would have liked though, but mostly 
due to timing of branching.



--
Jens Axboe

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  b5875222de2f ("NVMe: IO ending fixes on surprise removal")

from Linus' tree and commit:

  5bae7f73d378 ("nvme: move namespace scanning to common code")

from the block tree.

I fixed it up (the code was moved - I added the fix patch below) and
can carry the fix as necessary (no action is required).

However, there was another part to the former patch that I could not
quite figure out how to reproduce - the fix to nvme_dev_remove().

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 14:21:38 +1100
Subject: [PATCH] nvme: merge fix up for ns code movement

Signed-off-by: Stephen Rothwell 
---
 drivers/nvme/host/core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1437ff36e91c..1375a83593b5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
bool kill = nvme_io_incapable(ns->ctrl) &&
!blk_queue_dying(ns->queue);
 
-   if (kill)
+   if (kill) {
blk_set_queue_dying(ns->queue);
+
+   /*
+* The controller was shutdown first if we got here through
+* device removal. The shutdown may requeue outstanding
+* requests. These need to be aborted immediately so
+* del_gendisk doesn't block indefinitely for their completion.
+*/
+   blk_mq_abort_requeue_list(ns->queue);
+   }
if (ns->disk->flags & GENHD_FL_UP) {
if (blk_get_integrity(ns->disk))
blk_integrity_unregister(ns->disk);
-- 
2.6.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  b5875222de2f ("NVMe: IO ending fixes on surprise removal")

from Linus' tree and commit:

  5bae7f73d378 ("nvme: move namespace scanning to common code")

from the block tree.

I fixed it up (the code was moved - I added the fix patch below) and
can carry the fix as necessary (no action is required).

However, there was another part to the former patch that I could not
quite figure out how to reproduce - the fix to nvme_dev_remove().

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 14:21:38 +1100
Subject: [PATCH] nvme: merge fix up for ns code movement

Signed-off-by: Stephen Rothwell 
---
 drivers/nvme/host/core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1437ff36e91c..1375a83593b5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1118,8 +1118,17 @@ static void nvme_ns_remove(struct nvme_ns *ns)
bool kill = nvme_io_incapable(ns->ctrl) &&
!blk_queue_dying(ns->queue);
 
-   if (kill)
+   if (kill) {
blk_set_queue_dying(ns->queue);
+
+   /*
+* The controller was shutdown first if we got here through
+* device removal. The shutdown may requeue outstanding
+* requests. These need to be aborted immediately so
+* del_gendisk doesn't block indefinitely for their completion.
+*/
+   blk_mq_abort_requeue_list(ns->queue);
+   }
if (ns->disk->flags & GENHD_FL_UP) {
if (blk_get_integrity(ns->disk))
blk_integrity_unregister(ns->disk);
-- 
2.6.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/lightnvm.c

between commit:

  16f26c3aa9b9 ("lightnvm: replace req queue with nvmdev for lld")

from Linus' tree and commit:

  ac02dddec633 ("NVMe: fix build with CONFIG_NVM enabled")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/lightnvm.c
index 15f2acb4d5cd,09cf0b99d2fa..
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@@ -271,10 -273,9 +271,9 @@@ static int init_grps(struct nvm_id *nvm
return 0;
  }
  
 -static int nvme_nvm_identity(struct request_queue *q, struct nvm_id *nvm_id)
 +static int nvme_nvm_identity(struct nvm_dev *nvmdev, struct nvm_id *nvm_id)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_id *nvme_nvm_id;
struct nvme_nvm_command c = {};
int ret;
@@@ -308,13 -309,12 +307,12 @@@ out
return ret;
  }
  
 -static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u32 nlb,
 +static int nvme_nvm_get_l2p_tbl(struct nvm_dev *nvmdev, u64 slba, u32 nlb,
nvm_l2p_update_fn *update_l2p, void *priv)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_command c = {};
-   u32 len = queue_max_hw_sectors(dev->admin_q) << 9;
+   u32 len = queue_max_hw_sectors(ns->ctrl->admin_q) << 9;
u32 nlb_pr_rq = len / sizeof(u64);
u64 cmd_slba = slba;
void *entries;
@@@ -359,9 -359,8 +357,9 @@@ static int nvme_nvm_get_bb_tbl(struct n
int nr_blocks, nvm_bb_update_fn *update_bbtbl,
void *priv)
  {
 +  struct request_queue *q = nvmdev->q;
struct nvme_ns *ns = q->queuedata;
-   struct nvme_dev *dev = ns->dev;
+   struct nvme_ctrl *ctrl = ns->ctrl;
struct nvme_nvm_command c = {};
struct nvme_nvm_bb_tbl *bb_tbl;
int tblsz = sizeof(struct nvme_nvm_bb_tbl) + nr_blocks;
@@@ -415,11 -413,10 +413,10 @@@ out
return ret;
  }
  
 -static int nvme_nvm_set_bb_tbl(struct request_queue *q, struct nvm_rq *rqd,
 +static int nvme_nvm_set_bb_tbl(struct nvm_dev *nvmdev, struct nvm_rq *rqd,
int type)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_command c = {};
int ret = 0;
  
@@@ -517,12 -512,11 +514,11 @@@ static int nvme_nvm_erase_block(struct 
return nvme_submit_sync_cmd(q, (struct nvme_command *), NULL, 0);
  }
  
 -static void *nvme_nvm_create_dma_pool(struct request_queue *q, char *name)
 +static void *nvme_nvm_create_dma_pool(struct nvm_dev *nvmdev, char *name)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
  
-   return dma_pool_create(name, dev->dev, PAGE_SIZE, PAGE_SIZE, 0);
+   return dma_pool_create(name, ns->ctrl->dev, PAGE_SIZE, PAGE_SIZE, 0);
  }
  
  static void nvme_nvm_destroy_dma_pool(void *pool)
@@@ -573,19 -567,14 +569,20 @@@ void nvme_nvm_unregister(struct request
nvm_unregister(disk_name);
  }
  
 +/* move to shared place when used in multiple places. */
 +#define PCI_VENDOR_ID_CNEX 0x1d1d
 +#define PCI_DEVICE_ID_CNEX_WL 0x2807
 +#define PCI_DEVICE_ID_CNEX_QEMU 0x1f1f
 +
  int nvme_nvm_ns_supported(struct nvme_ns *ns, struct nvme_id_ns *id)
  {
-   struct nvme_dev *dev = ns->dev;
-   struct pci_dev *pdev = to_pci_dev(dev->dev);
+   struct nvme_ctrl *ctrl = ns->ctrl;
+   /* XXX: this is poking into PCI structures from generic code! */
+   struct pci_dev *pdev = to_pci_dev(ctrl->dev);
  
/* QEMU NVMe simulator - PCI ID + Vendor specific bit */
 -  if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x5845 &&
 +  if (pdev->vendor == PCI_VENDOR_ID_CNEX &&
 +  pdev->device == PCI_DEVICE_ID_CNEX_QEMU &&
id->vs[0] == 0x1)
return 1;
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/lightnvm.c

between commit:

  16f26c3aa9b9 ("lightnvm: replace req queue with nvmdev for lld")

from Linus' tree and commit:

  ac02dddec633 ("NVMe: fix build with CONFIG_NVM enabled")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/lightnvm.c
index 15f2acb4d5cd,09cf0b99d2fa..
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@@ -271,10 -273,9 +271,9 @@@ static int init_grps(struct nvm_id *nvm
return 0;
  }
  
 -static int nvme_nvm_identity(struct request_queue *q, struct nvm_id *nvm_id)
 +static int nvme_nvm_identity(struct nvm_dev *nvmdev, struct nvm_id *nvm_id)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_id *nvme_nvm_id;
struct nvme_nvm_command c = {};
int ret;
@@@ -308,13 -309,12 +307,12 @@@ out
return ret;
  }
  
 -static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u32 nlb,
 +static int nvme_nvm_get_l2p_tbl(struct nvm_dev *nvmdev, u64 slba, u32 nlb,
nvm_l2p_update_fn *update_l2p, void *priv)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_command c = {};
-   u32 len = queue_max_hw_sectors(dev->admin_q) << 9;
+   u32 len = queue_max_hw_sectors(ns->ctrl->admin_q) << 9;
u32 nlb_pr_rq = len / sizeof(u64);
u64 cmd_slba = slba;
void *entries;
@@@ -359,9 -359,8 +357,9 @@@ static int nvme_nvm_get_bb_tbl(struct n
int nr_blocks, nvm_bb_update_fn *update_bbtbl,
void *priv)
  {
 +  struct request_queue *q = nvmdev->q;
struct nvme_ns *ns = q->queuedata;
-   struct nvme_dev *dev = ns->dev;
+   struct nvme_ctrl *ctrl = ns->ctrl;
struct nvme_nvm_command c = {};
struct nvme_nvm_bb_tbl *bb_tbl;
int tblsz = sizeof(struct nvme_nvm_bb_tbl) + nr_blocks;
@@@ -415,11 -413,10 +413,10 @@@ out
return ret;
  }
  
 -static int nvme_nvm_set_bb_tbl(struct request_queue *q, struct nvm_rq *rqd,
 +static int nvme_nvm_set_bb_tbl(struct nvm_dev *nvmdev, struct nvm_rq *rqd,
int type)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
struct nvme_nvm_command c = {};
int ret = 0;
  
@@@ -517,12 -512,11 +514,11 @@@ static int nvme_nvm_erase_block(struct 
return nvme_submit_sync_cmd(q, (struct nvme_command *), NULL, 0);
  }
  
 -static void *nvme_nvm_create_dma_pool(struct request_queue *q, char *name)
 +static void *nvme_nvm_create_dma_pool(struct nvm_dev *nvmdev, char *name)
  {
 -  struct nvme_ns *ns = q->queuedata;
 +  struct nvme_ns *ns = nvmdev->q->queuedata;
-   struct nvme_dev *dev = ns->dev;
  
-   return dma_pool_create(name, dev->dev, PAGE_SIZE, PAGE_SIZE, 0);
+   return dma_pool_create(name, ns->ctrl->dev, PAGE_SIZE, PAGE_SIZE, 0);
  }
  
  static void nvme_nvm_destroy_dma_pool(void *pool)
@@@ -573,19 -567,14 +569,20 @@@ void nvme_nvm_unregister(struct request
nvm_unregister(disk_name);
  }
  
 +/* move to shared place when used in multiple places. */
 +#define PCI_VENDOR_ID_CNEX 0x1d1d
 +#define PCI_DEVICE_ID_CNEX_WL 0x2807
 +#define PCI_DEVICE_ID_CNEX_QEMU 0x1f1f
 +
  int nvme_nvm_ns_supported(struct nvme_ns *ns, struct nvme_id_ns *id)
  {
-   struct nvme_dev *dev = ns->dev;
-   struct pci_dev *pdev = to_pci_dev(dev->dev);
+   struct nvme_ctrl *ctrl = ns->ctrl;
+   /* XXX: this is poking into PCI structures from generic code! */
+   struct pci_dev *pdev = to_pci_dev(ctrl->dev);
  
/* QEMU NVMe simulator - PCI ID + Vendor specific bit */
 -  if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x5845 &&
 +  if (pdev->vendor == PCI_VENDOR_ID_CNEX &&
 +  pdev->device == PCI_DEVICE_ID_CNEX_QEMU &&
id->vs[0] == 0x1)
return 1;
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  1f390c1fde3a ("nvme: temporary fix for Apple controller reset")

from Linus' tree and commit:

  7a67cbea653e ("nvme: use offset instead of a struct for registers")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/pci.c
index 9e294ff4e652,a64d0baacc58..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -2704,23 -1805,12 +1805,24 @@@ static int nvme_dev_map(struct nvme_de
goto unmap;
}
  
-   cap = lo_hi_readq(>bar->cap);
+   cap = lo_hi_readq(dev->bar + NVME_REG_CAP);
+ 
dev->q_depth = min_t(int, NVME_CAP_MQES(cap) + 1, NVME_Q_DEPTH);
dev->db_stride = 1 << NVME_CAP_STRIDE(cap);
-   dev->dbs = ((void __iomem *)dev->bar) + 4096;
+   dev->dbs = dev->bar + 4096;
 +
 +  /*
 +   * Temporary fix for the Apple controller found in the MacBook8,1 and
 +   * some MacBook7,1 to avoid controller resets and data loss.
 +   */
 +  if (pdev->vendor == PCI_VENDOR_ID_APPLE && pdev->device == 0x2001) {
 +  dev->q_depth = 2;
 +  dev_warn(dev->dev, "detected Apple NVMe controller, set "
 +  "queue depth=%u to work around controller resets\n",
 +  dev->q_depth);
 +  }
 +
-   if (readl(>bar->vs) >= NVME_VS(1, 2))
+   if (readl(dev->bar + NVME_REG_VS) >= NVME_VS(1, 2))
dev->cmb = nvme_map_cmb(dev);
  
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/Makefile

between commit:

  c4699e70d1db ("lightnvm: Simplify config when disabled")

from Linus' tree and commit:

  21d34711e1b5 ("nvme: split command submission helpers out of pci.c")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/Makefile
index a5fe23952586,3e26dc921c38..
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@@ -1,5 -1,4 +1,5 @@@
  
  obj-$(CONFIG_BLK_DEV_NVME) += nvme.o
  
 -nvme-y+= core.o pci.o scsi.o lightnvm.o
 +lightnvm-$(CONFIG_NVM):= lightnvm.o
- nvme-y+= pci.o scsi.o $(lightnvm-y)
++nvme-y+= core.o pci.o scsi.o $(lightnvm-y)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/Makefile

between commit:

  c4699e70d1db ("lightnvm: Simplify config when disabled")

from Linus' tree and commit:

  21d34711e1b5 ("nvme: split command submission helpers out of pci.c")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/Makefile
index a5fe23952586,3e26dc921c38..
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@@ -1,5 -1,4 +1,5 @@@
  
  obj-$(CONFIG_BLK_DEV_NVME) += nvme.o
  
 -nvme-y+= core.o pci.o scsi.o lightnvm.o
 +lightnvm-$(CONFIG_NVM):= lightnvm.o
- nvme-y+= pci.o scsi.o $(lightnvm-y)
++nvme-y+= core.o pci.o scsi.o $(lightnvm-y)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/nvme/host/pci.c

between commit:

  1f390c1fde3a ("nvme: temporary fix for Apple controller reset")

from Linus' tree and commit:

  7a67cbea653e ("nvme: use offset instead of a struct for registers")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/nvme/host/pci.c
index 9e294ff4e652,a64d0baacc58..
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@@ -2704,23 -1805,12 +1805,24 @@@ static int nvme_dev_map(struct nvme_de
goto unmap;
}
  
-   cap = lo_hi_readq(>bar->cap);
+   cap = lo_hi_readq(dev->bar + NVME_REG_CAP);
+ 
dev->q_depth = min_t(int, NVME_CAP_MQES(cap) + 1, NVME_Q_DEPTH);
dev->db_stride = 1 << NVME_CAP_STRIDE(cap);
-   dev->dbs = ((void __iomem *)dev->bar) + 4096;
+   dev->dbs = dev->bar + 4096;
 +
 +  /*
 +   * Temporary fix for the Apple controller found in the MacBook8,1 and
 +   * some MacBook7,1 to avoid controller resets and data loss.
 +   */
 +  if (pdev->vendor == PCI_VENDOR_ID_APPLE && pdev->device == 0x2001) {
 +  dev->q_depth = 2;
 +  dev_warn(dev->dev, "detected Apple NVMe controller, set "
 +  "queue depth=%u to work around controller resets\n",
 +  dev->q_depth);
 +  }
 +
-   if (readl(>bar->vs) >= NVME_VS(1, 2))
+   if (readl(dev->bar + NVME_REG_VS) >= NVME_VS(1, 2))
dev->cmb = nvme_map_cmb(dev);
  
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/block/loop.c

between commit:

  f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")

from Linus' tree and commit:

  bc07c10a3603 ("block: loop: support DIO & AIO")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/block/loop.c
index 674f800a3b57,23376084a5cb..
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@@ -1486,47 -1669,25 +1669,26 @@@ static void loop_handle_cmd(struct loop
  {
const bool write = cmd->rq->cmd_flags & REQ_WRITE;
struct loop_device *lo = cmd->rq->q->queuedata;
 -  int ret = -EIO;
 +  int ret = 0;
  
 -  if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY))
 +  if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY)) {
 +  ret = -EIO;
goto failed;
 +  }
  
ret = do_req_filebacked(lo, cmd->rq);
 -
   failed:
-   blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
+   if (ret)
+   cmd->rq->errors = -EIO;
+   /* complete non-aio request */
+   if (!cmd->use_aio || ret)
 -  blk_mq_complete_request(cmd->rq);
++  blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
  }
  
- static void loop_queue_write_work(struct work_struct *work)
- {
-   struct loop_device *lo =
-   container_of(work, struct loop_device, write_work);
-   LIST_HEAD(cmd_list);
- 
-   spin_lock_irq(>lo_lock);
-  repeat:
-   list_splice_init(>write_cmd_head, _list);
-   spin_unlock_irq(>lo_lock);
- 
-   while (!list_empty(_list)) {
-   struct loop_cmd *cmd = list_first_entry(_list,
-   struct loop_cmd, list);
-   list_del_init(>list);
-   loop_handle_cmd(cmd);
-   }
- 
-   spin_lock_irq(>lo_lock);
-   if (!list_empty(>write_cmd_head))
-   goto repeat;
-   lo->write_started = false;
-   spin_unlock_irq(>lo_lock);
- }
- 
- static void loop_queue_read_work(struct work_struct *work)
+ static void loop_queue_work(struct kthread_work *work)
  {
struct loop_cmd *cmd =
-   container_of(work, struct loop_cmd, read_work);
+   container_of(work, struct loop_cmd, work);
  
loop_handle_cmd(cmd);
  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/block/loop.c

between commit:

  f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")

from Linus' tree and commit:

  bc07c10a3603 ("block: loop: support DIO & AIO")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/block/loop.c
index 674f800a3b57,23376084a5cb..
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@@ -1486,47 -1669,25 +1669,26 @@@ static void loop_handle_cmd(struct loop
  {
const bool write = cmd->rq->cmd_flags & REQ_WRITE;
struct loop_device *lo = cmd->rq->q->queuedata;
 -  int ret = -EIO;
 +  int ret = 0;
  
 -  if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY))
 +  if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY)) {
 +  ret = -EIO;
goto failed;
 +  }
  
ret = do_req_filebacked(lo, cmd->rq);
 -
   failed:
-   blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
+   if (ret)
+   cmd->rq->errors = -EIO;
+   /* complete non-aio request */
+   if (!cmd->use_aio || ret)
 -  blk_mq_complete_request(cmd->rq);
++  blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
  }
  
- static void loop_queue_write_work(struct work_struct *work)
- {
-   struct loop_device *lo =
-   container_of(work, struct loop_device, write_work);
-   LIST_HEAD(cmd_list);
- 
-   spin_lock_irq(>lo_lock);
-  repeat:
-   list_splice_init(>write_cmd_head, _list);
-   spin_unlock_irq(>lo_lock);
- 
-   while (!list_empty(_list)) {
-   struct loop_cmd *cmd = list_first_entry(_list,
-   struct loop_cmd, list);
-   list_del_init(>list);
-   loop_handle_cmd(cmd);
-   }
- 
-   spin_lock_irq(>lo_lock);
-   if (!list_empty(>write_cmd_head))
-   goto repeat;
-   lo->write_started = false;
-   spin_unlock_irq(>lo_lock);
- }
- 
- static void loop_queue_read_work(struct work_struct *work)
+ static void loop_queue_work(struct kthread_work *work)
  {
struct loop_cmd *cmd =
-   container_of(work, struct loop_cmd, read_work);
+   container_of(work, struct loop_cmd, work);
  
loop_handle_cmd(cmd);
  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/fs-writeback.c

between commit:

  006a0973ed02 ("writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes 
and always call wait_sb_inodes()")

from Linus' tree and commits:

  1ed8d48c57bf ("writeback: bdi_for_each_wb() iteration is memcg ID based not 
blkcg")
  8a1270cda7b4 ("writeback: remove wb_writeback_work->single_wait/done")

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/fs-writeback.c
index ae0f438c2ee6,f4f0f228a530..
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -844,24 -783,45 +783,46 @@@ static void bdi_split_work_to_wbs(struc
struct wb_iter iter;
  
might_sleep();
 -
 -  if (!bdi_has_dirty_io(bdi))
 -  return;
  restart:
rcu_read_lock();
-   bdi_for_each_wb(wb, bdi, , next_blkcg_id) {
+   bdi_for_each_wb(wb, bdi, , next_memcg_id) {
+   DEFINE_WB_COMPLETION_ONSTACK(fallback_work_done);
+   struct wb_writeback_work fallback_work;
+   struct wb_writeback_work *work;
+   long nr_pages;
+ 
 -  if (!wb_has_dirty_io(wb) ||
 -  (skip_if_busy && writeback_in_progress(wb)))
 +  /* SYNC_ALL writes out I_DIRTY_TIME too */
 +  if (!wb_has_dirty_io(wb) &&
 +  (base_work->sync_mode == WB_SYNC_NONE ||
 +   list_empty(>b_dirty_time)))
 +  continue;
 +  if (skip_if_busy && writeback_in_progress(wb))
continue;
  
-   base_work->nr_pages = wb_split_bdi_pages(wb, nr_pages);
-   if (!wb_clone_and_queue_work(wb, base_work)) {
-   next_blkcg_id = wb->blkcg_css->id + 1;
-   rcu_read_unlock();
-   wb_wait_for_single_work(bdi, base_work);
-   goto restart;
+   nr_pages = wb_split_bdi_pages(wb, base_work->nr_pages);
+ 
+   work = kmalloc(sizeof(*work), GFP_ATOMIC);
+   if (work) {
+   *work = *base_work;
+   work->nr_pages = nr_pages;
+   work->auto_free = 1;
+   wb_queue_work(wb, work);
+   continue;
}
+ 
+   /* alloc failed, execute synchronously using on-stack fallback 
*/
+   work = _work;
+   *work = *base_work;
+   work->nr_pages = nr_pages;
+   work->auto_free = 0;
+   work->done = _work_done;
+ 
+   wb_queue_work(wb, work);
+ 
+   next_memcg_id = wb->memcg_css->id + 1;
+   rcu_read_unlock();
+   wb_wait_for_completion(bdi, _work_done);
+   goto restart;
}
rcu_read_unlock();
  }
@@@ -900,10 -860,9 +861,8 @@@ static void bdi_split_work_to_wbs(struc
  {
might_sleep();
  
 -  if (bdi_has_dirty_io(bdi) &&
 -  (!skip_if_busy || !writeback_in_progress(>wb))) {
 +  if (!skip_if_busy || !writeback_in_progress(>wb)) {
base_work->auto_free = 0;
-   base_work->single_wait = 0;
-   base_work->single_done = 0;
wb_queue_work(>wb, base_work);
}
  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/fs-writeback.c

between commit:

  006a0973ed02 (writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes 
and always call wait_sb_inodes())

from Linus' tree and commits:

  1ed8d48c57bf (writeback: bdi_for_each_wb() iteration is memcg ID based not 
blkcg)
  8a1270cda7b4 (writeback: remove wb_writeback_work-single_wait/done)

from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/fs-writeback.c
index ae0f438c2ee6,f4f0f228a530..
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -844,24 -783,45 +783,46 @@@ static void bdi_split_work_to_wbs(struc
struct wb_iter iter;
  
might_sleep();
 -
 -  if (!bdi_has_dirty_io(bdi))
 -  return;
  restart:
rcu_read_lock();
-   bdi_for_each_wb(wb, bdi, iter, next_blkcg_id) {
+   bdi_for_each_wb(wb, bdi, iter, next_memcg_id) {
+   DEFINE_WB_COMPLETION_ONSTACK(fallback_work_done);
+   struct wb_writeback_work fallback_work;
+   struct wb_writeback_work *work;
+   long nr_pages;
+ 
 -  if (!wb_has_dirty_io(wb) ||
 -  (skip_if_busy  writeback_in_progress(wb)))
 +  /* SYNC_ALL writes out I_DIRTY_TIME too */
 +  if (!wb_has_dirty_io(wb) 
 +  (base_work-sync_mode == WB_SYNC_NONE ||
 +   list_empty(wb-b_dirty_time)))
 +  continue;
 +  if (skip_if_busy  writeback_in_progress(wb))
continue;
  
-   base_work-nr_pages = wb_split_bdi_pages(wb, nr_pages);
-   if (!wb_clone_and_queue_work(wb, base_work)) {
-   next_blkcg_id = wb-blkcg_css-id + 1;
-   rcu_read_unlock();
-   wb_wait_for_single_work(bdi, base_work);
-   goto restart;
+   nr_pages = wb_split_bdi_pages(wb, base_work-nr_pages);
+ 
+   work = kmalloc(sizeof(*work), GFP_ATOMIC);
+   if (work) {
+   *work = *base_work;
+   work-nr_pages = nr_pages;
+   work-auto_free = 1;
+   wb_queue_work(wb, work);
+   continue;
}
+ 
+   /* alloc failed, execute synchronously using on-stack fallback 
*/
+   work = fallback_work;
+   *work = *base_work;
+   work-nr_pages = nr_pages;
+   work-auto_free = 0;
+   work-done = fallback_work_done;
+ 
+   wb_queue_work(wb, work);
+ 
+   next_memcg_id = wb-memcg_css-id + 1;
+   rcu_read_unlock();
+   wb_wait_for_completion(bdi, fallback_work_done);
+   goto restart;
}
rcu_read_unlock();
  }
@@@ -900,10 -860,9 +861,8 @@@ static void bdi_split_work_to_wbs(struc
  {
might_sleep();
  
 -  if (bdi_has_dirty_io(bdi) 
 -  (!skip_if_busy || !writeback_in_progress(bdi-wb))) {
 +  if (!skip_if_busy || !writeback_in_progress(bdi-wb)) {
base_work-auto_free = 0;
-   base_work-single_wait = 0;
-   base_work-single_done = 0;
wb_queue_work(bdi-wb, base_work);
}
  }
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm.c

between commit:

  bd4aaf8f9b85 ("dm: fix dm_merge_bvec regression on 32 bit systems")

from Linus' tree and commit:

  8ae126660fdd ("block: kill merge_bvec_fn() completely")

from the block tree.

I fixed it up (the latter removed the code updated by the former) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  drivers/md/dm.c

between commit:

  bd4aaf8f9b85 (dm: fix dm_merge_bvec regression on 32 bit systems)

from Linus' tree and commit:

  8ae126660fdd (block: kill merge_bvec_fn() completely)

from the block tree.

I fixed it up (the latter removed the code updated by the former) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
mm/backing-dev.c between commit aad653a0bc09 ("block: discard
bdi_unregister() in favour of bdi_destroy()") from Linus' tree and
various commits from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required - though it may be worth while merging what you
had Linus merge and fixing up the conflicts yourself).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/backing-dev.c
index 000e7b3b9896,887d72a85b5e..
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@@ -387,49 -744,91 +744,75 @@@ int bdi_init(struct backing_dev_info *b
bdi->min_ratio = 0;
bdi->max_ratio = 100;
bdi->max_prop_frac = FPROP_FRAC_BASE;
-   spin_lock_init(>wb_lock);
INIT_LIST_HEAD(>bdi_list);
-   INIT_LIST_HEAD(>work_list);
+   init_waitqueue_head(>wb_waitq);
  
-   bdi_wb_init(>wb, bdi);
+   err = wb_init(>wb, bdi, GFP_KERNEL);
+   if (err)
+   return err;
  
-   for (i = 0; i < NR_BDI_STAT_ITEMS; i++) {
-   err = percpu_counter_init(>bdi_stat[i], 0, GFP_KERNEL);
-   if (err)
-   goto err;
-   }
+   bdi->wb_congested.state = 0;
+   bdi->wb.congested = >wb_congested;
  
-   bdi->dirty_exceeded = 0;
+   cgwb_bdi_init(bdi);
+   return 0;
+ }
+ EXPORT_SYMBOL(bdi_init);
  
-   bdi->bw_time_stamp = jiffies;
-   bdi->written_stamp = 0;
+ int bdi_register(struct backing_dev_info *bdi, struct device *parent,
+   const char *fmt, ...)
+ {
+   va_list args;
+   struct device *dev;
  
-   bdi->balanced_dirty_ratelimit = INIT_BW;
-   bdi->dirty_ratelimit = INIT_BW;
-   bdi->write_bandwidth = INIT_BW;
-   bdi->avg_write_bandwidth = INIT_BW;
+   if (bdi->dev)   /* The driver needs to use separate queues per device */
+   return 0;
  
-   err = fprop_local_init_percpu(>completions, GFP_KERNEL);
+   va_start(args, fmt);
+   dev = device_create_vargs(bdi_class, parent, MKDEV(0, 0), bdi, fmt, 
args);
+   va_end(args);
+   if (IS_ERR(dev))
+   return PTR_ERR(dev);
  
-   if (err) {
- err:
-   while (i--)
-   percpu_counter_destroy(>bdi_stat[i]);
-   }
+   bdi->dev = dev;
  
-   return err;
+   bdi_debug_register(bdi, dev_name(dev));
+   set_bit(WB_registered, >wb.state);
+ 
+   spin_lock_bh(_lock);
+   list_add_tail_rcu(>bdi_list, _list);
+   spin_unlock_bh(_lock);
+ 
+   trace_writeback_bdi_register(bdi);
+   return 0;
  }
- EXPORT_SYMBOL(bdi_init);
+ EXPORT_SYMBOL(bdi_register);
  
- void bdi_destroy(struct backing_dev_info *bdi)
+ int bdi_register_dev(struct backing_dev_info *bdi, dev_t dev)
  {
-   int i;
+   return bdi_register(bdi, NULL, "%u:%u", MAJOR(dev), MINOR(dev));
+ }
+ EXPORT_SYMBOL(bdi_register_dev);
  
-   bdi_wb_shutdown(bdi);
-   bdi_set_min_ratio(bdi, 0);
+ /*
+  * Remove bdi from bdi_list, and ensure that it is no longer visible
+  */
+ static void bdi_remove_from_list(struct backing_dev_info *bdi)
+ {
+   spin_lock_bh(_lock);
+   list_del_rcu(>bdi_list);
+   spin_unlock_bh(_lock);
  
-   WARN_ON(!list_empty(>work_list));
-   WARN_ON(delayed_work_pending(>wb.dwork));
+   synchronize_rcu_expedited();
+ }
+ 
 -/*
 - * Called when the device behind @bdi has been removed or ejected.
 - *
 - * We can't really do much here except for reducing the dirty ratio at
 - * the moment.  In the future we should be able to set a flag so that
 - * the filesystem can handle errors at mark_inode_dirty time instead
 - * of only at writeback time.
 - */
 -void bdi_unregister(struct backing_dev_info *bdi)
 -{
 -  if (WARN_ON_ONCE(!bdi->dev))
 -  return;
 -
 -  bdi_set_min_ratio(bdi, 0);
 -}
 -EXPORT_SYMBOL(bdi_unregister);
 -
+ void bdi_destroy(struct backing_dev_info *bdi)
+ {
+   /* make sure nobody finds us on the bdi_list anymore */
+   bdi_remove_from_list(bdi);
+   wb_shutdown(>wb);
++  bdi_set_min_ratio(bdi, 0);
+   cgwb_bdi_destroy(bdi);
  
if (bdi->dev) {
bdi_debug_unregister(bdi);


pgpFKxwfALVHs.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/block/nvme-core.c between commit fec558b5f178 ("NVMe: fix type
warning on 32-bit") from Linus' tree and commit d29ec8241c10 ("nvme:
submit internal commands through the block layer") from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/block/nvme-core.c
index 683dff272562,513908ff46c4..
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@@ -1745,12 -1714,10 +1714,11 @@@ static int nvme_submit_io(struct nvme_n
struct nvme_dev *dev = ns->dev;
struct nvme_user_io io;
struct nvme_command c;
-   unsigned length, meta_len, prp_len;
+   unsigned length, meta_len;
int status, write;
-   struct nvme_iod *iod;
dma_addr_t meta_dma = 0;
void *meta = NULL;
 +  void __user *metadata;
  
if (copy_from_user(, uio, sizeof(io)))
return -EFAULT;
@@@ -1778,18 -1731,21 +1732,23 @@@
return -EINVAL;
}
  
-   if (IS_ERR(iod))
-   return PTR_ERR(iod);
+   length = (io.nblocks + 1) << ns->lba_shift;
+   meta_len = (io.nblocks + 1) * ns->ms;
+   write = io.opcode & 1;
++  metadata = (void __user *)(unsigned long)io.metadata;
  
-   prp_len = nvme_setup_prps(dev, iod, length, GFP_KERNEL);
-   if (length != prp_len) {
-   status = -ENOMEM;
-   goto unmap;
-   }
if (meta_len) {
-   meta = dma_alloc_coherent(>pci_dev->dev, meta_len,
+   if (((io.metadata & 3) || !io.metadata) && !ns->ext)
+   return -EINVAL;
+ 
+   if (ns->ext) {
+   length += meta_len;
+   meta_len = 0;
+   }
+ 
+   meta = dma_alloc_coherent(dev->dev, meta_len,
_dma, GFP_KERNEL);
 +
if (!meta) {
status = -ENOMEM;
goto unmap;
@@@ -1813,19 -1770,18 +1772,17 @@@
c.rw.reftag = cpu_to_le32(io.reftag);
c.rw.apptag = cpu_to_le16(io.apptag);
c.rw.appmask = cpu_to_le16(io.appmask);
-   c.rw.prp1 = cpu_to_le64(sg_dma_address(iod->sg));
-   c.rw.prp2 = cpu_to_le64(iod->first_dma);
c.rw.metadata = cpu_to_le64(meta_dma);
-   status = nvme_submit_io_cmd(dev, ns, , NULL);
+ 
+   status = __nvme_submit_sync_cmd(ns->queue, , NULL,
+   (void __user *)io.addr, length, NULL, 0);
   unmap:
-   nvme_unmap_user_pages(dev, write, iod);
-   nvme_free_iod(dev, iod);
if (meta) {
if (status == NVME_SC_SUCCESS && !write) {
 -  if (copy_to_user((void __user *)io.metadata, meta,
 -  meta_len))
 +  if (copy_to_user(metadata, meta, meta_len))
status = -EFAULT;
}
-   dma_free_coherent(>pci_dev->dev, meta_len, meta, meta_dma);
+   dma_free_coherent(dev->dev, meta_len, meta, meta_dma);
}
return status;
  }


pgpf2avOsz4L4.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/block/nvme-core.c between commit fec558b5f178 (NVMe: fix type
warning on 32-bit) from Linus' tree and commit d29ec8241c10 (nvme:
submit internal commands through the block layer) from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/block/nvme-core.c
index 683dff272562,513908ff46c4..
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@@ -1745,12 -1714,10 +1714,11 @@@ static int nvme_submit_io(struct nvme_n
struct nvme_dev *dev = ns-dev;
struct nvme_user_io io;
struct nvme_command c;
-   unsigned length, meta_len, prp_len;
+   unsigned length, meta_len;
int status, write;
-   struct nvme_iod *iod;
dma_addr_t meta_dma = 0;
void *meta = NULL;
 +  void __user *metadata;
  
if (copy_from_user(io, uio, sizeof(io)))
return -EFAULT;
@@@ -1778,18 -1731,21 +1732,23 @@@
return -EINVAL;
}
  
-   if (IS_ERR(iod))
-   return PTR_ERR(iod);
+   length = (io.nblocks + 1)  ns-lba_shift;
+   meta_len = (io.nblocks + 1) * ns-ms;
+   write = io.opcode  1;
++  metadata = (void __user *)(unsigned long)io.metadata;
  
-   prp_len = nvme_setup_prps(dev, iod, length, GFP_KERNEL);
-   if (length != prp_len) {
-   status = -ENOMEM;
-   goto unmap;
-   }
if (meta_len) {
-   meta = dma_alloc_coherent(dev-pci_dev-dev, meta_len,
+   if (((io.metadata  3) || !io.metadata)  !ns-ext)
+   return -EINVAL;
+ 
+   if (ns-ext) {
+   length += meta_len;
+   meta_len = 0;
+   }
+ 
+   meta = dma_alloc_coherent(dev-dev, meta_len,
meta_dma, GFP_KERNEL);
 +
if (!meta) {
status = -ENOMEM;
goto unmap;
@@@ -1813,19 -1770,18 +1772,17 @@@
c.rw.reftag = cpu_to_le32(io.reftag);
c.rw.apptag = cpu_to_le16(io.apptag);
c.rw.appmask = cpu_to_le16(io.appmask);
-   c.rw.prp1 = cpu_to_le64(sg_dma_address(iod-sg));
-   c.rw.prp2 = cpu_to_le64(iod-first_dma);
c.rw.metadata = cpu_to_le64(meta_dma);
-   status = nvme_submit_io_cmd(dev, ns, c, NULL);
+ 
+   status = __nvme_submit_sync_cmd(ns-queue, c, NULL,
+   (void __user *)io.addr, length, NULL, 0);
   unmap:
-   nvme_unmap_user_pages(dev, write, iod);
-   nvme_free_iod(dev, iod);
if (meta) {
if (status == NVME_SC_SUCCESS  !write) {
 -  if (copy_to_user((void __user *)io.metadata, meta,
 -  meta_len))
 +  if (copy_to_user(metadata, meta, meta_len))
status = -EFAULT;
}
-   dma_free_coherent(dev-pci_dev-dev, meta_len, meta, meta_dma);
+   dma_free_coherent(dev-dev, meta_len, meta, meta_dma);
}
return status;
  }


pgpf2avOsz4L4.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
mm/backing-dev.c between commit aad653a0bc09 (block: discard
bdi_unregister() in favour of bdi_destroy()) from Linus' tree and
various commits from the block tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required - though it may be worth while merging what you
had Linus merge and fixing up the conflicts yourself).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/backing-dev.c
index 000e7b3b9896,887d72a85b5e..
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@@ -387,49 -744,91 +744,75 @@@ int bdi_init(struct backing_dev_info *b
bdi-min_ratio = 0;
bdi-max_ratio = 100;
bdi-max_prop_frac = FPROP_FRAC_BASE;
-   spin_lock_init(bdi-wb_lock);
INIT_LIST_HEAD(bdi-bdi_list);
-   INIT_LIST_HEAD(bdi-work_list);
+   init_waitqueue_head(bdi-wb_waitq);
  
-   bdi_wb_init(bdi-wb, bdi);
+   err = wb_init(bdi-wb, bdi, GFP_KERNEL);
+   if (err)
+   return err;
  
-   for (i = 0; i  NR_BDI_STAT_ITEMS; i++) {
-   err = percpu_counter_init(bdi-bdi_stat[i], 0, GFP_KERNEL);
-   if (err)
-   goto err;
-   }
+   bdi-wb_congested.state = 0;
+   bdi-wb.congested = bdi-wb_congested;
  
-   bdi-dirty_exceeded = 0;
+   cgwb_bdi_init(bdi);
+   return 0;
+ }
+ EXPORT_SYMBOL(bdi_init);
  
-   bdi-bw_time_stamp = jiffies;
-   bdi-written_stamp = 0;
+ int bdi_register(struct backing_dev_info *bdi, struct device *parent,
+   const char *fmt, ...)
+ {
+   va_list args;
+   struct device *dev;
  
-   bdi-balanced_dirty_ratelimit = INIT_BW;
-   bdi-dirty_ratelimit = INIT_BW;
-   bdi-write_bandwidth = INIT_BW;
-   bdi-avg_write_bandwidth = INIT_BW;
+   if (bdi-dev)   /* The driver needs to use separate queues per device */
+   return 0;
  
-   err = fprop_local_init_percpu(bdi-completions, GFP_KERNEL);
+   va_start(args, fmt);
+   dev = device_create_vargs(bdi_class, parent, MKDEV(0, 0), bdi, fmt, 
args);
+   va_end(args);
+   if (IS_ERR(dev))
+   return PTR_ERR(dev);
  
-   if (err) {
- err:
-   while (i--)
-   percpu_counter_destroy(bdi-bdi_stat[i]);
-   }
+   bdi-dev = dev;
  
-   return err;
+   bdi_debug_register(bdi, dev_name(dev));
+   set_bit(WB_registered, bdi-wb.state);
+ 
+   spin_lock_bh(bdi_lock);
+   list_add_tail_rcu(bdi-bdi_list, bdi_list);
+   spin_unlock_bh(bdi_lock);
+ 
+   trace_writeback_bdi_register(bdi);
+   return 0;
  }
- EXPORT_SYMBOL(bdi_init);
+ EXPORT_SYMBOL(bdi_register);
  
- void bdi_destroy(struct backing_dev_info *bdi)
+ int bdi_register_dev(struct backing_dev_info *bdi, dev_t dev)
  {
-   int i;
+   return bdi_register(bdi, NULL, %u:%u, MAJOR(dev), MINOR(dev));
+ }
+ EXPORT_SYMBOL(bdi_register_dev);
  
-   bdi_wb_shutdown(bdi);
-   bdi_set_min_ratio(bdi, 0);
+ /*
+  * Remove bdi from bdi_list, and ensure that it is no longer visible
+  */
+ static void bdi_remove_from_list(struct backing_dev_info *bdi)
+ {
+   spin_lock_bh(bdi_lock);
+   list_del_rcu(bdi-bdi_list);
+   spin_unlock_bh(bdi_lock);
  
-   WARN_ON(!list_empty(bdi-work_list));
-   WARN_ON(delayed_work_pending(bdi-wb.dwork));
+   synchronize_rcu_expedited();
+ }
+ 
 -/*
 - * Called when the device behind @bdi has been removed or ejected.
 - *
 - * We can't really do much here except for reducing the dirty ratio at
 - * the moment.  In the future we should be able to set a flag so that
 - * the filesystem can handle errors at mark_inode_dirty time instead
 - * of only at writeback time.
 - */
 -void bdi_unregister(struct backing_dev_info *bdi)
 -{
 -  if (WARN_ON_ONCE(!bdi-dev))
 -  return;
 -
 -  bdi_set_min_ratio(bdi, 0);
 -}
 -EXPORT_SYMBOL(bdi_unregister);
 -
+ void bdi_destroy(struct backing_dev_info *bdi)
+ {
+   /* make sure nobody finds us on the bdi_list anymore */
+   bdi_remove_from_list(bdi);
+   wb_shutdown(bdi-wb);
++  bdi_set_min_ratio(bdi, 0);
+   cgwb_bdi_destroy(bdi);
  
if (bdi-dev) {
bdi_debug_unregister(bdi);


pgpFKxwfALVHs.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
mm/page-writeback.c between commit 464d1387acb9 ("writeback: use |1
instead of +1 to protect against div by zero") from Linus' tree and
commit de1fff37b278 ("writeback: s/bdi/wb/ in mm/page-writeback.c")
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/page-writeback.c
index eb59f7eea508,e1514d5b4e9b..
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -802,27 -990,27 +990,27 @@@ static void wb_position_ratio(struct di
 * threshold, so that the occasional writes won't be blocked and active
 * writes can rampup the threshold quickly.
 */
-   bdi_thresh = max(bdi_thresh, (limit - dirty) / 8);
+   wb_thresh = max(wb_thresh, (limit - dtc->dirty) / 8);
/*
-* scale global setpoint to bdi's:
-*  bdi_setpoint = setpoint * bdi_thresh / thresh
+* scale global setpoint to wb's:
+*  wb_setpoint = setpoint * wb_thresh / thresh
 */
-   x = div_u64((u64)bdi_thresh << 16, thresh | 1);
-   bdi_setpoint = setpoint * (u64)x >> 16;
 -  x = div_u64((u64)wb_thresh << 16, dtc->thresh + 1);
++  x = div_u64((u64)wb_thresh << 16, dtc->thresh | 1);
+   wb_setpoint = setpoint * (u64)x >> 16;
/*
-* Use span=(8*write_bw) in single bdi case as indicated by
-* (thresh - bdi_thresh ~= 0) and transit to bdi_thresh in JBOD case.
+* Use span=(8*write_bw) in single wb case as indicated by
+* (thresh - wb_thresh ~= 0) and transit to wb_thresh in JBOD case.
 *
-*bdi_threshthresh - bdi_thresh
-* span = -- * (8 * write_bw) + --- * bdi_thresh
-*  threshthresh
+*wb_threshthresh - wb_thresh
+* span = - * (8 * write_bw) + -- * wb_thresh
+* thresh   thresh
 */
-   span = (thresh - bdi_thresh + 8 * write_bw) * (u64)x >> 16;
-   x_intercept = bdi_setpoint + span;
+   span = (dtc->thresh - wb_thresh + 8 * write_bw) * (u64)x >> 16;
+   x_intercept = wb_setpoint + span;
  
-   if (bdi_dirty < x_intercept - span / 4) {
-   pos_ratio = div64_u64(pos_ratio * (x_intercept - bdi_dirty),
- (x_intercept - bdi_setpoint) | 1);
+   if (dtc->wb_dirty < x_intercept - span / 4) {
+   pos_ratio = div64_u64(pos_ratio * (x_intercept - dtc->wb_dirty),
 -x_intercept - wb_setpoint + 1);
++(x_intercept - wb_setpoint) | 1);
} else
pos_ratio /= 4;
  


pgpvYkYPlzBu1.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
include/linux/blkdev.h between commit 336b7e1f2309 ("block: remove
export for blk_queue_bio") from Linus' tree and commit d40f75a06dd6
("writeback, blkcg: restructure blk_{set|clear}_queue_congested()")
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/blkdev.h
index 5d93a6645e88,31cd832cebb7..
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -821,25 -787,8 +787,6 @@@ extern int scsi_cmd_ioctl(struct reques
  extern int sg_scsi_ioctl(struct request_queue *, struct gendisk *, fmode_t,
 struct scsi_ioctl_command __user *);
  
- /*
-  * A queue has just exitted congestion.  Note this in the global counter of
-  * congested queues, and wake up anyone who was waiting for requests to be
-  * put back.
-  */
- static inline void blk_clear_queue_congested(struct request_queue *q, int 
sync)
- {
-   clear_bdi_congested(>backing_dev_info, sync);
- }
- 
- /*
-  * A queue has just entered congestion.  Flag that in the queue's VM-visible
-  * state flags and increment the global gounter of congested queues.
-  */
- static inline void blk_set_queue_congested(struct request_queue *q, int sync)
- {
-   set_bdi_congested(>backing_dev_info, sync);
- }
 -extern void blk_queue_bio(struct request_queue *q, struct bio *bio);
--
  extern void blk_start_queue(struct request_queue *q);
  extern void blk_stop_queue(struct request_queue *q);
  extern void blk_sync_queue(struct request_queue *q);


pgpoLKcEzX8Aw.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
mm/page-writeback.c between commit 464d1387acb9 (writeback: use |1
instead of +1 to protect against div by zero) from Linus' tree and
commit de1fff37b278 (writeback: s/bdi/wb/ in mm/page-writeback.c)
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/page-writeback.c
index eb59f7eea508,e1514d5b4e9b..
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -802,27 -990,27 +990,27 @@@ static void wb_position_ratio(struct di
 * threshold, so that the occasional writes won't be blocked and active
 * writes can rampup the threshold quickly.
 */
-   bdi_thresh = max(bdi_thresh, (limit - dirty) / 8);
+   wb_thresh = max(wb_thresh, (limit - dtc-dirty) / 8);
/*
-* scale global setpoint to bdi's:
-*  bdi_setpoint = setpoint * bdi_thresh / thresh
+* scale global setpoint to wb's:
+*  wb_setpoint = setpoint * wb_thresh / thresh
 */
-   x = div_u64((u64)bdi_thresh  16, thresh | 1);
-   bdi_setpoint = setpoint * (u64)x  16;
 -  x = div_u64((u64)wb_thresh  16, dtc-thresh + 1);
++  x = div_u64((u64)wb_thresh  16, dtc-thresh | 1);
+   wb_setpoint = setpoint * (u64)x  16;
/*
-* Use span=(8*write_bw) in single bdi case as indicated by
-* (thresh - bdi_thresh ~= 0) and transit to bdi_thresh in JBOD case.
+* Use span=(8*write_bw) in single wb case as indicated by
+* (thresh - wb_thresh ~= 0) and transit to wb_thresh in JBOD case.
 *
-*bdi_threshthresh - bdi_thresh
-* span = -- * (8 * write_bw) + --- * bdi_thresh
-*  threshthresh
+*wb_threshthresh - wb_thresh
+* span = - * (8 * write_bw) + -- * wb_thresh
+* thresh   thresh
 */
-   span = (thresh - bdi_thresh + 8 * write_bw) * (u64)x  16;
-   x_intercept = bdi_setpoint + span;
+   span = (dtc-thresh - wb_thresh + 8 * write_bw) * (u64)x  16;
+   x_intercept = wb_setpoint + span;
  
-   if (bdi_dirty  x_intercept - span / 4) {
-   pos_ratio = div64_u64(pos_ratio * (x_intercept - bdi_dirty),
- (x_intercept - bdi_setpoint) | 1);
+   if (dtc-wb_dirty  x_intercept - span / 4) {
+   pos_ratio = div64_u64(pos_ratio * (x_intercept - dtc-wb_dirty),
 -x_intercept - wb_setpoint + 1);
++(x_intercept - wb_setpoint) | 1);
} else
pos_ratio /= 4;
  


pgpvYkYPlzBu1.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
include/linux/blkdev.h between commit 336b7e1f2309 (block: remove
export for blk_queue_bio) from Linus' tree and commit d40f75a06dd6
(writeback, blkcg: restructure blk_{set|clear}_queue_congested())
from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/blkdev.h
index 5d93a6645e88,31cd832cebb7..
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -821,25 -787,8 +787,6 @@@ extern int scsi_cmd_ioctl(struct reques
  extern int sg_scsi_ioctl(struct request_queue *, struct gendisk *, fmode_t,
 struct scsi_ioctl_command __user *);
  
- /*
-  * A queue has just exitted congestion.  Note this in the global counter of
-  * congested queues, and wake up anyone who was waiting for requests to be
-  * put back.
-  */
- static inline void blk_clear_queue_congested(struct request_queue *q, int 
sync)
- {
-   clear_bdi_congested(q-backing_dev_info, sync);
- }
- 
- /*
-  * A queue has just entered congestion.  Flag that in the queue's VM-visible
-  * state flags and increment the global gounter of congested queues.
-  */
- static inline void blk_set_queue_congested(struct request_queue *q, int sync)
- {
-   set_bdi_congested(q-backing_dev_info, sync);
- }
 -extern void blk_queue_bio(struct request_queue *q, struct bio *bio);
--
  extern void blk_start_queue(struct request_queue *q);
  extern void blk_stop_queue(struct request_queue *q);
  extern void blk_sync_queue(struct request_queue *q);


pgpoLKcEzX8Aw.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the block tree with Linus' tree

[Mike Snitzer]

On Mon, Jun 01 2015 at 12:56am -0400,
Stephen Rothwell  wrote:

> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> drivers/md/dm.c between commits 3a1407559a59 ("dm: fix NULL pointer
> when clone_and_map_rq returns !DM_MAPIO_REMAPPED") and e5d8de32cc02
> ("dm: fix false warning in free_rq_clone() for unmapped requests") from
> Linus' tree and commit 5f1b670d0bef ("block, dm: don't copy bios for
> request clones") from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

That matches the merge that I'm carrying in linux-dm.git's for-next too.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with Linus' tree

[Mike Snitzer]

On Mon, Jun 01 2015 at 12:56am -0400,
Stephen Rothwell s...@canb.auug.org.au wrote:

 Hi Jens,
 
 Today's linux-next merge of the block tree got a conflict in
 drivers/md/dm.c between commits 3a1407559a59 (dm: fix NULL pointer
 when clone_and_map_rq returns !DM_MAPIO_REMAPPED) and e5d8de32cc02
 (dm: fix false warning in free_rq_clone() for unmapped requests) from
 Linus' tree and commit 5f1b670d0bef (block, dm: don't copy bios for
 request clones) from the block tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

That matches the merge that I'm carrying in linux-dm.git's for-next too.

Thanks,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/dm.c between commits 3a1407559a59 ("dm: fix NULL pointer
when clone_and_map_rq returns !DM_MAPIO_REMAPPED") and e5d8de32cc02
("dm: fix false warning in free_rq_clone() for unmapped requests") from
Linus' tree and commit 5f1b670d0bef ("block, dm: don't copy bios for
request clones") from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/md/dm.c
index 2caf492890d6,38837f8ea327..
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@@ -1087,8 -1036,8 +1036,6 @@@ static void free_rq_clone(struct reques
struct dm_rq_target_io *tio = clone->end_io_data;
struct mapped_device *md = tio->md;
  
-   blk_rq_unprep_clone(clone);
 -  WARN_ON_ONCE(must_be_mapped && !clone->q);
--
if (md->type == DM_TYPE_MQ_REQUEST_BASED)
/* stacked on blk-mq queue(s) */
tio->ti->type->release_clone_rq(clone);
@@@ -1977,13 -1887,9 +1893,9 @@@ static int map_request(struct dm_rq_tar
dm_kill_unmapped_request(rq, r);
return r;
}
 -  if (IS_ERR(clone))
 -  return DM_MAPIO_REQUEUE;
 +  if (r != DM_MAPIO_REMAPPED)
 +  return r;
-   if (setup_clone(clone, rq, tio, GFP_ATOMIC)) {
-   /* -ENOMEM */
-   ti->type->release_clone_rq(clone);
-   return DM_MAPIO_REQUEUE;
-   }
+   setup_clone(clone, rq, tio);
}
  
switch (r) {


pgpQicSfi4iHF.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/dm.c between commits 3a1407559a59 (dm: fix NULL pointer
when clone_and_map_rq returns !DM_MAPIO_REMAPPED) and e5d8de32cc02
(dm: fix false warning in free_rq_clone() for unmapped requests) from
Linus' tree and commit 5f1b670d0bef (block, dm: don't copy bios for
request clones) from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/md/dm.c
index 2caf492890d6,38837f8ea327..
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@@ -1087,8 -1036,8 +1036,6 @@@ static void free_rq_clone(struct reques
struct dm_rq_target_io *tio = clone-end_io_data;
struct mapped_device *md = tio-md;
  
-   blk_rq_unprep_clone(clone);
 -  WARN_ON_ONCE(must_be_mapped  !clone-q);
--
if (md-type == DM_TYPE_MQ_REQUEST_BASED)
/* stacked on blk-mq queue(s) */
tio-ti-type-release_clone_rq(clone);
@@@ -1977,13 -1887,9 +1893,9 @@@ static int map_request(struct dm_rq_tar
dm_kill_unmapped_request(rq, r);
return r;
}
 -  if (IS_ERR(clone))
 -  return DM_MAPIO_REQUEUE;
 +  if (r != DM_MAPIO_REMAPPED)
 +  return r;
-   if (setup_clone(clone, rq, tio, GFP_ATOMIC)) {
-   /* -ENOMEM */
-   ti-type-release_clone_rq(clone);
-   return DM_MAPIO_REQUEUE;
-   }
+   setup_clone(clone, rq, tio);
}
  
switch (r) {


pgpQicSfi4iHF.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
block/blk-mq.c between commit ac2111753ca9 ("blk-mq: initialize 'struct
request' and associated data to zero") from Linus' tree and commit
cef4e5c345d3 ("blk-mq: ensure that request and PDU data are zeroed at
init time") from the block tree.

I fixed it up (just formatted differently - I used the block tree
version) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp5jeIb72Kdg.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
block/blk-mq.c between commit ac2111753ca9 (blk-mq: initialize 'struct
request' and associated data to zero) from Linus' tree and commit
cef4e5c345d3 (blk-mq: ensure that request and PDU data are zeroed at
init time) from the block tree.

I fixed it up (just formatted differently - I used the block tree
version) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp5jeIb72Kdg.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/ata/libata-core.c between commit 72dd299d5039 ("libata: allow
sata_sil24 to opt-out of tag ordered submission") from Linus' tree and
commit 98bd4be1ba95 ("libata: move sas ata tag allocation to
libata-scsi.c") from the block tree.

I fixed it up (I used the version from the block tree and then added
the following patch) and can carry the fix as necessary (no action is
required).

From: Stephen Rothwell 
Date: Tue, 27 Jan 2015 14:59:51 +1100
Subject: [PATCH] libata: fix for move of sas tag allocation code

Signed-off-by: Stephen Rothwell 
---
 drivers/ata/libata-scsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index fd9be1756f0d..055e75d2176e 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -4240,7 +4240,10 @@ int ata_sas_allocate_tag(struct ata_port *ap)
unsigned int i, tag;
 
for (i = 0, tag = ap->sas_last_tag + 1; i < max_queue; i++, tag++) {
-   tag = tag < max_queue ? tag : 0;
+   if (ap->flags & ATA_FLAG_LOWTAG)
+   tag = i;
+   else
+   tag = tag < max_queue ? tag : 0;
 
/* the last tag is reserved for internal command. */
if (tag == ATA_TAG_INTERNAL)
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpnOfJ45ZbBq.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/ata/libata-core.c between commit 72dd299d5039 (libata: allow
sata_sil24 to opt-out of tag ordered submission) from Linus' tree and
commit 98bd4be1ba95 (libata: move sas ata tag allocation to
libata-scsi.c) from the block tree.

I fixed it up (I used the version from the block tree and then added
the following patch) and can carry the fix as necessary (no action is
required).

From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 27 Jan 2015 14:59:51 +1100
Subject: [PATCH] libata: fix for move of sas tag allocation code

Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
 drivers/ata/libata-scsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index fd9be1756f0d..055e75d2176e 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -4240,7 +4240,10 @@ int ata_sas_allocate_tag(struct ata_port *ap)
unsigned int i, tag;
 
for (i = 0, tag = ap-sas_last_tag + 1; i  max_queue; i++, tag++) {
-   tag = tag  max_queue ? tag : 0;
+   if (ap-flags  ATA_FLAG_LOWTAG)
+   tag = i;
+   else
+   tag = tag  max_queue ? tag : 0;
 
/* the last tag is reserved for internal command. */
if (tag == ATA_TAG_INTERNAL)
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpnOfJ45ZbBq.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/bio-integrity.c between commit eec70897d81b ("bio-integrity: Drop
bio_integrity_verify BUG_ON in post bip->bip_iter world") from Linus'
tree and commit bf36f9cfa6d3 ("fs/bio-integrity: remove duplicate code")
from the block tree.

I fixed it up (by using the latter - however, I am not sure that this is
completely correct as the BUG_ON more or less returns?) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpBlWba7XxU0.pgp
Description: PGP signature

linux-next: manual merge of the block tree with Linus' tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/bio-integrity.c between commit eec70897d81b (bio-integrity: Drop
bio_integrity_verify BUG_ON in post bip-bip_iter world) from Linus'
tree and commit bf36f9cfa6d3 (fs/bio-integrity: remove duplicate code)
from the block tree.

I fixed it up (by using the latter - however, I am not sure that this is
completely correct as the BUG_ON more or less returns?) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpBlWba7XxU0.pgp
Description: PGP signature

linux-next: manual merge of the block tree with Linus' tree

[Mark Brown]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in block/blk-mq.c 
between commit d6a25b31315327 (blk-mq: support partial I/O completions) from 
Linus' tree and commit af5040da01ef (blktrace: fix accounting of partially 
completed requests) from the block tree.

I fixed it up by dropping the hunk from af5040da01ef in a way git doesn't seem 
easily persuaded to show as a resolution and can carry the fix as necessary (no 
action is required).


pgpVigd6ZKY39.pgp
Description: PGP signature

linux-next: manual merge of the block tree with Linus' tree

[Mark Brown]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in block/blk-mq.c 
between commit d6a25b31315327 (blk-mq: support partial I/O completions) from 
Linus' tree and commit af5040da01ef (blktrace: fix accounting of partially 
completed requests) from the block tree.

I fixed it up by dropping the hunk from af5040da01ef in a way git doesn't seem 
easily persuaded to show as a resolution and can carry the fix as necessary (no 
action is required).


pgpVigd6ZKY39.pgp
Description: PGP signature

Re: linux-next: manual merge of the block tree with the tree

[Stephen Rothwell]

Hi all,

On Fri, 8 Nov 2013 09:15:08 -0700 Jens Axboe  wrote:
>
> On Fri, Nov 08 2013, Jens Axboe wrote:
> > On Thu, Nov 07 2013, Christoph Hellwig wrote:
> > > Btw, I have to state that I very much disagree with dropping the
> > > direct I/O kernel changes, and I also very much disagree with keeping
> > > the immutable iovecs in.
> > > 
> > > For the latter I think the immutable iovecs are useful and do want to
> > > see them eventually, but they were merged at the latest possible point
> > > in the merge window and cause breakage all over the tree, so they very
> > > clearly are not ready at this point, and I fear even more breakage if
> > > they do get merged.
> > 
> > I agree, I've had this very conversation with Kent as well. The merge of
> > it has gone a lot worse than I had feared, and the resulting series at
> > this point is a non-bisectable mess. The fallback plan was to pull it
> > from the 3.13 tree and shove it into a 3.14 tree with more for-next
> > simmering.
> > 
> > It is in progress, just takes a while...
> 
> And it's done and pushed out. for-3.13/drivers is still missing the
> bcache bits, those will get merged back in once they don't depend on the
> immutable changes anymore.
> 
> Dave, this should make your life easier. And Stephen, if you pull the
> new for-next, it should make yours a lot easier as well.

I have added the aio-driect tree back for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpWUbCLp4Cfm.pgp
Description: PGP signature

Re: linux-next: manual merge of the block tree with the tree

[Stephen Rothwell]

Hi all,

On Fri, 8 Nov 2013 09:15:08 -0700 Jens Axboe ax...@kernel.dk wrote:

 On Fri, Nov 08 2013, Jens Axboe wrote:
  On Thu, Nov 07 2013, Christoph Hellwig wrote:
   Btw, I have to state that I very much disagree with dropping the
   direct I/O kernel changes, and I also very much disagree with keeping
   the immutable iovecs in.
   
   For the latter I think the immutable iovecs are useful and do want to
   see them eventually, but they were merged at the latest possible point
   in the merge window and cause breakage all over the tree, so they very
   clearly are not ready at this point, and I fear even more breakage if
   they do get merged.
  
  I agree, I've had this very conversation with Kent as well. The merge of
  it has gone a lot worse than I had feared, and the resulting series at
  this point is a non-bisectable mess. The fallback plan was to pull it
  from the 3.13 tree and shove it into a 3.14 tree with more for-next
  simmering.
  
  It is in progress, just takes a while...
 
 And it's done and pushed out. for-3.13/drivers is still missing the
 bcache bits, those will get merged back in once they don't depend on the
 immutable changes anymore.
 
 Dave, this should make your life easier. And Stephen, if you pull the
 new for-next, it should make yours a lot easier as well.

I have added the aio-driect tree back for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpWUbCLp4Cfm.pgp
Description: PGP signature

Re: linux-next: manual merge of the block tree with the tree

[Zach Brown]

> > > That make sense? I can show you more concretely what I'm working on if
> > > you want. Or if I'm full of crap and this is useless for what you guys
> > > want I'm sure you'll let me know :)
> > 
> > It sounds interesting, but also a little confusing at this point, at
> > least from the non-block side of view.
> 
> Zach, you want to chime in? He was involved in the discussion yesterday,
> he might be able to explain this stuff better than I.

I can try.  I may not do the *best* job because I've been on the
periphery of most of this since I left the proof of concept back at
Oracle :).

The first part is passing in pages instead of mapped addresses.  That's
where the iov_iter argument came from.  A ham-fisted proof of concept to
try to abstract iterating over any old type of memory.  But it's not
*really* abstract because dio magically knows (look for gross
iov_iter_has_iovec() callers) whether the memory is in iovecs or bio
pages when its verifying alignment, pinning or not, etc.  In the end
it's little more than syntactic sugar to try and pretend that two
interfaces are one.

For expedience, this iov_iter approach used the loop's bio to store the
pages in the iov_iter rather than translating the bio's pages to a page
array in the iov_iter.

So the first part of what I think Kent is picturing is to take that to
its logical conclusion and have the caller describe the io memory and
offset with a bio instead of explicit address and offset arguments.
This way dio can do nice bio management operations to kick off its
device bios rather than having to clumsily build them from either
incoming pages or mapped user addresses that are hidden in iov_iter.

I'm imagining cutting the current dio up in to two phases.  One that
pins user pages and puts them in bios and one that maps those file bios
to device bios and submits them.  Then the fop method becomes the second
phase so that loop can call it with its file bios.  Call it
->submit_file_bio() instead of ->do_direct_IO(), maybe?

The other part of this series that isn't getting as much attention,
though, is async submission and completion.  This patch introduces a
weird in-kernel aio submission interface that adds special cases to aio.
In this new bio world order we could get rid of that complication by
relying on the bio's ->bi_end_io() for completion.

I suppose a high level view of this strategy is to move more towards a
stack where layers have matching inputs and outputs.  If both dio and
loop take bios as input and translate them into submitted output bios
then the stacking becomes more natural.

That's the blue sky fantasy anyway.  There's a lot of detail being
glossed over.  I want to see what the patches look like.

- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with the tree

[Jens Axboe]

On Fri, Nov 08 2013, Jens Axboe wrote:
> On Thu, Nov 07 2013, Christoph Hellwig wrote:
> > Btw, I have to state that I very much disagree with dropping the
> > direct I/O kernel changes, and I also very much disagree with keeping
> > the immutable iovecs in.
> > 
> > For the latter I think the immutable iovecs are useful and do want to
> > see them eventually, but they were merged at the latest possible point
> > in the merge window and cause breakage all over the tree, so they very
> > clearly are not ready at this point, and I fear even more breakage if
> > they do get merged.
> 
> I agree, I've had this very conversation with Kent as well. The merge of
> it has gone a lot worse than I had feared, and the resulting series at
> this point is a non-bisectable mess. The fallback plan was to pull it
> from the 3.13 tree and shove it into a 3.14 tree with more for-next
> simmering.
> 
> It is in progress, just takes a while...

And it's done and pushed out. for-3.13/drivers is still missing the
bcache bits, those will get merged back in once they don't depend on the
immutable changes anymore.

Dave, this should make your life easier. And Stephen, if you pull the
new for-next, it should make yours a lot easier as well.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with the tree

[Jens Axboe]

On Thu, Nov 07 2013, Christoph Hellwig wrote:
> Btw, I have to state that I very much disagree with dropping the
> direct I/O kernel changes, and I also very much disagree with keeping
> the immutable iovecs in.
> 
> For the latter I think the immutable iovecs are useful and do want to
> see them eventually, but they were merged at the latest possible point
> in the merge window and cause breakage all over the tree, so they very
> clearly are not ready at this point, and I fear even more breakage if
> they do get merged.

I agree, I've had this very conversation with Kent as well. The merge of
it has gone a lot worse than I had feared, and the resulting series at
this point is a non-bisectable mess. The fallback plan was to pull it
from the 3.13 tree and shove it into a 3.14 tree with more for-next
simmering.

It is in progress, just takes a while...

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with the tree

[Dave Kleikamp]

On 11/08/2013 01:33 AM, Christoph Hellwig wrote:
> Btw, I have to state that I very much disagree with dropping the
> direct I/O kernel changes, and I also very much disagree with keeping
> the immutable iovecs in.
> 
> For the latter I think the immutable iovecs are useful and do want to
> see them eventually, but they were merged at the latest possible point
> in the merge window and cause breakage all over the tree, so they very
> clearly are not ready at this point, and I fear even more breakage if
> they do get merged.
> 
> The changes for direct I/O from kernel space have been in for a long
> time, and they are blocking multiple consumers of the interface from
> getting submitted for about a year now.  Even if the guts of the
> direct-io code will get a write based on another patchset from Kent
> that will go on top of the immutable iovec changes we need the
> interfaces now and not another year down the road.

Sorry Christoph,
I guess I made a rash decision to pull this from linux-next. I
underestimated the dependencies others had on this.

Stephen,
How about you pick this up again for now? Unfortunately, I'm going to be
on a cruise next week and basically out of touch after today until a
week from Monday. That will give Kent some more time to ponder things
before I ask Linus to merge it.

Thanks,
Sorry for being a hassle.

Shaggy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with the tree

[Kent Overstreet]

On Fri, Nov 08, 2013 at 12:32:51AM -0800, Christoph Hellwig wrote:
> On Fri, Nov 08, 2013 at 12:17:37AM -0800, Kent Overstreet wrote:
> > The core issue isn't whether the IO is going to a block based filesystem
> > (but thanks for pointing out that that's not necessarily true!) but
> > whether we want to work with pinned pages or not. If pinned pages are ok
> > for everything, then bios as a common interface work - likely evolving
> > them a bit to be more general (it's just bi_bdev and bi_sector that's
> > actually block specific) - and IMO that would be far preferable to this
> > abstraction layer.
> > 
> > If OTOH we need a common interface that's also for places where we can't
> > afford the overhead of pinning user pages - that's a different story,
> > and maybe we do need all this infrastructure then. That's why I'm asking
> > about the stuff you meantioned, I'm honestly not sure.
> 
> For both of them we will deal with kernel-allocated pages that are never
> mapped to userspace.  This is likely to be true for all the consumers
> of in-kernel aio/dio as the existing interfaces handle user pages just
> fine.

Ok, that's good to know.

> > What I'm working towards though is a clean separation between buffered
> > and direct code paths, so that buffered IO can continue work with iovs
> > and for O_DIRECT the first thing you do is fill out a bio with pinned
> > pages and send it down to filesystem code or wherever it's going to go.
> 
> I don't think pushing bios above the fs interface is a good idea. Note
> that the iovecs come from userspace for the user pages cases, so there
> is little we can do about that, and non-bio based direct I/O
> implementations generally work directly at just that level and never
> even touch the direct-io.c code.

Bios can point to userspage pages just fine (and they do today for DIO
to block devices/block based filesystems today). Don't think of bios as
"block device IOs", just think of them as the equivalent of an iovec +
iov_iter except instead of (potentially userspace) pointers you have
page pointers. That's the core part of what they do (and even if we
don't standardize on bios for that we should standardize on _something_
for that functionality).

Here's the helper function I wrote for my dio rewrite - it should really
take an iov_iter instead of uaddr and len, but user iovec -> bio is the
easy bit:

http://evilpiepirate.org/git/linux-bcache.git/commit/?h=block_stuff=4462c03167767c656986afaf981f891705fd5d3b

> If you want to redo the ->direct_IO address_space operation and
> generic_file_direct_write and the direct I/O side of
> generic_file_aio_read (both of which aren't anywhere near as generic as
> the name claims) I'm all for it, but it really won't affect the consumer
> of the in-kernel aio/dio code.

I'm skeptical, but I'm way too tired to make good arguments and this
touches on too much code that I'm less familiar with.

also the flow of control in this code is such a goddamn clusterfuck I
don't even know what to say.

I'll dig more into the ecryptfs and target aio stuff tomorrow though.

> > That make sense? I can show you more concretely what I'm working on if
> > you want. Or if I'm full of crap and this is useless for what you guys
> > want I'm sure you'll let me know :)
> 
> It sounds interesting, but also a little confusing at this point, at
> least from the non-block side of view.

Zack, you want to chime in? He was involved in the discussion yesterday,
he might be able to explain this stuff better than I.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the block tree with the tree

[Christoph Hellwig]

On Fri, Nov 08, 2013 at 12:17:37AM -0800, Kent Overstreet wrote:
> The core issue isn't whether the IO is going to a block based filesystem
> (but thanks for pointing out that that's not necessarily true!) but
> whether we want to work with pinned pages or not. If pinned pages are ok
> for everything, then bios as a common interface work - likely evolving
> them a bit to be more general (it's just bi_bdev and bi_sector that's
> actually block specific) - and IMO that would be far preferable to this
> abstraction layer.
> 
> If OTOH we need a common interface that's also for places where we can't
> afford the overhead of pinning user pages - that's a different story,
> and maybe we do need all this infrastructure then. That's why I'm asking
> about the stuff you meantioned, I'm honestly not sure.

For both of them we will deal with kernel-allocated pages that are never
mapped to userspace.  This is likely to be true for all the consumers
of in-kernel aio/dio as the existing interfaces handle user pages just
fine.

> What I'm working towards though is a clean separation between buffered
> and direct code paths, so that buffered IO can continue work with iovs
> and for O_DIRECT the first thing you do is fill out a bio with pinned
> pages and send it down to filesystem code or wherever it's going to go.

I don't think pushing bios above the fs interface is a good idea. Note
that the iovecs come from userspace for the user pages cases, so there
is little we can do about that, and non-bio based direct I/O
implementations generally work directly at just that level and never
even touch the direct-io.c code.

If you want to redo the ->direct_IO address_space operation and
generic_file_direct_write and the direct I/O side of
generic_file_aio_read (both of which aren't anywhere near as generic as
the name claims) I'm all for it, but it really won't affect the consumer
of the in-kernel aio/dio code.

> That make sense? I can show you more concretely what I'm working on if
> you want. Or if I'm full of crap and this is useless for what you guys
> want I'm sure you'll let me know :)

It sounds interesting, but also a little confusing at this point, at
least from the non-block side of view.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/