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

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..000000000000
--- 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, &ctrl->async_event_sqe,
  			sizeof(struct nvme_command), DMA_TO_DEVICE);
- 	nvme_rdma_stop_and_free_queue(&ctrl->queues[0]);
- 	blk_cleanup_queue(ctrl->ctrl.admin_q);
- 	blk_mq_free_tag_set(&ctrl->admin_tag_set);
- 	nvme_rdma_dev_put(ctrl->device);
+ 	nvme_rdma_stop_queue(&ctrl->queues[0]);
+ 	if (remove) {
+ 		blk_cleanup_queue(ctrl->ctrl.admin_q);
+ 		nvme_rdma_free_tagset(&ctrl->ctrl, true);
+ 	}
+ 	nvme_rdma_free_queue(&ctrl->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->ctrl, true);
+ 		if (IS_ERR(ctrl->ctrl.admin_tagset))
+ 			goto out_free_queue;
+ 
+ 		ctrl->ctrl.admin_q = blk_mq_init_queue(&ctrl->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(&ctrl->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->ctrl, NVME_REG_CAP,
+ 			&ctrl->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->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->ctrl);
+ 	if (error)
+ 		goto out_cleanup_queue;
+ 
+ 	error = nvme_rdma_alloc_qe(ctrl->queues[0].device->dev,
+ 			&ctrl->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->ctrl, true);
+ out_free_queue:
+ 	nvme_rdma_free_queue(&ctrl->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->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;
+ 
+ 	if (new) {
+ 		ctrl->ctrl.tagset = nvme_rdma_alloc_tagset(&ctrl->ctrl, false);
+ 		if (IS_ERR(ctrl->ctrl.tagset))
+ 			goto out_free_io_queues;
+ 
+ 		ctrl->ctrl.connect_q = blk_mq_init_queue(&ctrl->tag_set);
+ 		if (IS_ERR(ctrl->ctrl.connect_q)) {
+ 			ret = PTR_ERR(ctrl->ctrl.connect_q);
+ 			goto out_free_tag_set;
+ 		}
+ 	} else {
+ 		ret = blk_mq_reinit_tagset(&ctrl->tag_set,
+ 					   nvme_rdma_reinit_request);
+ 		if (ret)
+ 			goto out_free_io_queues;
+ 
+ 		blk_mq_update_nr_hw_queues(&ctrl->tag_set,
+ 			ctrl->ctrl.queue_count - 1);
+ 	}
+ 
+ 	ret = nvme_rdma_start_io_queues(ctrl);
+ 	if (ret)
+ 		goto out_cleanup_connect_q;
+ 
+ 	return 0;
+ 
+ out_cleanup_connect_q:
+ 	if (new)
+ 		blk_cleanup_queue(ctrl->ctrl.connect_q);
+ out_free_tag_set:
+ 	if (new)
+ 		nvme_rdma_free_tagset(&ctrl->ctrl, false);
+ out_free_io_queues:
+ 	nvme_rdma_free_io_queues(ctrl);
+ 	return ret;
  }
  
  static void nvme_rdma_free_ctrl(struct nvme_ctrl *nctrl)
@@@ -927,12 -1111,8 +1118,12 @@@ static int nvme_rdma_map_sg_fr(struct n
  	struct nvme_keyed_sgl_desc *sg = &c->common.dptr.ksgl;
  	int nr;
  
 -	nr = ib_map_mr_sg(req->mr, req->sg_table.sgl, count, NULL, PAGE_SIZE);
 +	/*
 +	 * Align the MR to a 4K page size to match the ctrl page size and
 +	 * the block virtual boundary.
 +	 */
 +	nr = ib_map_mr_sg(req->mr, req->sg_table.sgl, count, NULL, SZ_4K);
- 	if (nr < count) {
+ 	if (unlikely(nr < count)) {
  		if (nr < 0)
  			return nr;
  		return -EINVAL;

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Hi all,

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

  drivers/nvme/target/tcp.c

between commit:

  d920abd1e7c4 ("nvmet-tcp: Fix a possible UAF in queue intialization setup")

from Linus' tree and commit:

  675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")

from the block tree.

I fixed it up (I am not sure this is necessary - 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/target/tcp.c
index 197fc2ecb164,4336fe048e43..000000000000
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@@ -910,8 -932,8 +933,10 @@@ static int nvmet_tcp_handle_icreq(struc
  	iov.iov_base = icresp;
  	iov.iov_len = sizeof(*icresp);
  	ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len);
--	if (ret < 0)
 -		goto free_crypto;
++	if (ret < 0) {
++		queue->state = NVMET_TCP_Q_FAILED;
 +		return ret; /* queue removal will cleanup */
++	}
  
  	queue->state = NVMET_TCP_Q_LIVE;
  	nvmet_prepare_receive_pdu(queue);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

Hi all,

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

  io_uring/net.c

between commit:

  78d0d2063bab ("io_uring/net: disable partial retries for recvmsg with cmsg")

from Linus' tree and commit:

  88fc8b8463b0 ("io_uring/net: initalize msghdr->msg_inq to known value")

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 io_uring/net.c
index 4b8e84768d2a,369167e45fa8..000000000000
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@@ -790,19 -794,17 +803,20 @@@ retry_multishot
  	flags = sr->msg_flags;
  	if (force_nonblock)
  		flags |= MSG_DONTWAIT;
 -	if (flags & MSG_WAITALL)
 -		min_ret = iov_iter_count(&kmsg->msg.msg_iter);
  
  	kmsg->msg.msg_get_inq = 1;
+ 	kmsg->msg.msg_inq = -1U;
 -	if (req->flags & REQ_F_APOLL_MULTISHOT)
 +	if (req->flags & REQ_F_APOLL_MULTISHOT) {
  		ret = io_recvmsg_multishot(sock, sr, kmsg, flags,
  					   &mshot_finished);
 -	else
 +	} else {
 +		/* disable partial retry for recvmsg with cmsg attached */
 +		if (flags & MSG_WAITALL && !kmsg->msg.msg_controllen)
 +			min_ret = iov_iter_count(&kmsg->msg.msg_iter);
 +
  		ret = __sys_recvmsg_sock(sock, &kmsg->msg, sr->umsg,
  					 kmsg->uaddr, flags);
 +	}
  
  	if (ret < min_ret) {
  		if (ret == -EAGAIN && force_nonblock) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

Hi all,

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

  io_uring/alloc_cache.h

between commit:

  fd30d1cdcc4f ("io_uring: fix poll/netmsg alloc caches")

from Linus' tree and commits:

  66eb95a0cf1c ("io_uring: Move from hlist to io_wq_work_node")
  16afed16c7a6 ("io_uring: Add KASAN support for alloc_caches")

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 io_uring/alloc_cache.h
index c2cde88aeed5,3aba7b356320..000000000000
--- a/io_uring/alloc_cache.h
+++ b/io_uring/alloc_cache.h
@@@ -23,12 -25,13 +25,14 @@@ static inline bool io_alloc_cache_put(s
  
  static inline struct io_cache_entry *io_alloc_cache_get(struct io_alloc_cache *cache)
  {
- 	if (!hlist_empty(&cache->list)) {
- 		struct hlist_node *node = cache->list.first;
+ 	if (cache->list.next) {
+ 		struct io_cache_entry *entry;
  
- 		hlist_del(node);
+ 		entry = container_of(cache->list.next, struct io_cache_entry, node);
+ 		kasan_unpoison_range(entry, cache->elem_size);
+ 		cache->list.next = cache->list.next->next;
 +		cache->nr_cached--;
- 		return container_of(node, struct io_cache_entry, node);
+ 		return entry;
  	}
  
  	return NULL;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jens Axboe]

On 11/20/22 7:46 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   io_uring/net.c
> 
> between commit:
> 
>   91482864768a ("io_uring: fix multishot accept request leaks")
> 
> from Linus' tree and commits:
> 
>   01661287389d ("io_uring: revert "io_uring fix multishot accept ordering"")
>   6488182c989a ("io_uring: remove allow_overflow parameter")
> 
> from the block tree.
> 
> I fixed it up (I just used the latter version where they conflicted) 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 fixed up the 6.2 io_uring branch and for-next, so you should not be
seeing this one again.

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hi all,

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

  io_uring/net.c

between commit:

  91482864768a ("io_uring: fix multishot accept request leaks")

from Linus' tree and commits:

  01661287389d ("io_uring: revert "io_uring fix multishot accept ordering"")
  6488182c989a ("io_uring: remove allow_overflow parameter")

from the block tree.

I fixed it up (I just used the latter version where they conflicted) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3966 bytes --]

Hi all,

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

  fs/xattr.c

between commit:

  705191b03d50 ("fs: fix acl translation")

from Linus' tree and commits:

  f8b398dcacfe ("fs: split off setxattr_copy and do_setxattr function from setxattr")
  8997d04977f5 ("fs: split off do_getxattr from getxattr")

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/xattr.c
index 998045165916,0b9f296a7071..000000000000
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@@ -557,26 -556,60 +556,61 @@@ int setxattr_copy(const char __user *na
  	if (error < 0)
  		return error;
  
- 	if (size) {
- 		if (size > XATTR_SIZE_MAX)
+ 	error = 0;
+ 	if (ctx->size) {
+ 		if (ctx->size > XATTR_SIZE_MAX)
  			return -E2BIG;
- 		kvalue = kvmalloc(size, GFP_KERNEL);
- 		if (!kvalue)
- 			return -ENOMEM;
- 		if (copy_from_user(kvalue, value, size)) {
- 			error = -EFAULT;
- 			goto out;
+ 
+ 		ctx->kvalue = vmemdup_user(ctx->cvalue, ctx->size);
+ 		if (IS_ERR(ctx->kvalue)) {
+ 			error = PTR_ERR(ctx->kvalue);
+ 			ctx->kvalue = NULL;
  		}
- 		if ((strcmp(kname, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
- 		    (strcmp(kname, XATTR_NAME_POSIX_ACL_DEFAULT) == 0))
- 			posix_acl_fix_xattr_from_user(mnt_userns, d_inode(d),
- 						      kvalue, size);
  	}
  
- 	error = vfs_setxattr(mnt_userns, d, kname, kvalue, size, flags);
- out:
- 	kvfree(kvalue);
+ 	return error;
+ }
+ 
+ static void setxattr_convert(struct user_namespace *mnt_userns,
 -			struct xattr_ctx *ctx)
++			struct dentry *d, struct xattr_ctx *ctx)
+ {
+ 	if (ctx->size &&
+ 		((strcmp(ctx->kname->name, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
+ 		(strcmp(ctx->kname->name, XATTR_NAME_POSIX_ACL_DEFAULT) == 0)))
 -		posix_acl_fix_xattr_from_user(mnt_userns, ctx->kvalue, ctx->size);
++		posix_acl_fix_xattr_from_user(mnt_userns, d_inode(d),
++					      ctx->kvalue, ctx->size);
+ }
+ 
+ int do_setxattr(struct user_namespace *mnt_userns, struct dentry *dentry,
+ 		struct xattr_ctx *ctx)
+ {
 -	setxattr_convert(mnt_userns, ctx);
++	setxattr_convert(mnt_userns, dentry, ctx);
+ 	return vfs_setxattr(mnt_userns, dentry, ctx->kname->name,
+ 			ctx->kvalue, ctx->size, ctx->flags);
+ }
+ 
+ static long
+ setxattr(struct user_namespace *mnt_userns, struct dentry *d,
+ 	const char __user *name, const void __user *value, size_t size,
+ 	int flags)
+ {
+ 	struct xattr_name kname;
+ 	struct xattr_ctx ctx = {
+ 		.cvalue   = value,
+ 		.kvalue   = NULL,
+ 		.size     = size,
+ 		.kname    = &kname,
+ 		.flags    = flags,
+ 	};
+ 	int error;
  
+ 	error = setxattr_copy(name, &ctx);
+ 	if (error)
+ 		return error;
+ 
+ 	error = do_setxattr(mnt_userns, d, &ctx);
+ 
+ 	kvfree(ctx.kvalue);
  	return error;
  }
  
@@@ -668,11 -694,10 +695,11 @@@ do_getxattr(struct user_namespace *mnt_
  	if (error > 0) {
  		if ((strcmp(kname, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
  		    (strcmp(kname, XATTR_NAME_POSIX_ACL_DEFAULT) == 0))
 -			posix_acl_fix_xattr_to_user(mnt_userns, ctx->kvalue, error);
 +			posix_acl_fix_xattr_to_user(mnt_userns, d_inode(d),
- 						    kvalue, error);
- 		if (size && copy_to_user(value, kvalue, error))
++						    ctx->kvalue, error);
+ 		if (ctx->size && copy_to_user(ctx->value, ctx->kvalue, error))
  			error = -EFAULT;
- 	} else if (error == -ERANGE && size >= XATTR_SIZE_MAX) {
+ 	} else if (error == -ERANGE && ctx->size >= XATTR_SIZE_MAX) {
  		/* The file system tried to returned a value bigger
  		   than XATTR_SIZE_MAX bytes. Not possible. */
  		error = -E2BIG;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

Hi all,

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

  drivers/nvme/target/configfs.c

between commit:

  0c48645a7f39 ("nvmet: revert "nvmet: make discovery NQN configurable"")

from Linus' tree and commit:

  73d77c53ff34 ("nvmet: don't fold lines")

from the block tree.

I fixed it up (The former removed some code that was updated 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christoph Hellwig]

On Fri, Nov 26, 2021 at 10:38:57AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/bdev.c
> 
> between commit:
> 
>   efcf5932230b ("block: avoid to touch unloaded module instance when opening bdev")
> 
> from Linus' tree and commit:
> 
>   a1525fbf1d76 ("block: remove the GENHD_FL_HIDDEN check in blkdev_get_no_open")
> 

The merge looks good, thanks.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Hi all,

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

  block/bdev.c

between commit:

  efcf5932230b ("block: avoid to touch unloaded module instance when opening bdev")

from Linus' tree and commit:

  a1525fbf1d76 ("block: remove the GENHD_FL_HIDDEN check in blkdev_get_no_open")

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/bdev.c
index b1d087e5e205,ae063041f291..000000000000
--- a/block/bdev.c
+++ b/block/bdev.c
@@@ -753,10 -753,10 +753,6 @@@ struct block_device *blkdev_get_no_open
  
  	if (!bdev)
  		return NULL;
- 	if ((bdev->bd_disk->flags & GENHD_FL_HIDDEN)) {
 -	if (!try_module_get(bdev->bd_disk->fops->owner)) {
--		put_device(&bdev->bd_device);
--		return NULL;
--	}
  
  	return bdev;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Hi all,

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

  drivers/scsi/ufs/ufshpb.c

between commit:

  09d9e4d04187 ("scsi: ufs: ufshpb: Remove HPB2.0 flows")

from Linus' tree and commit:

  0bf6d96cb829 ("block: remove blk_{get,put}_request")

from the block tree.

I fixed it up (the former removed the code modified by the latter, so I
did 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

Hi all,

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

  fs/io_uring.c

between commits:

  4ea672ab694c ("io_uring: fix ltimeout unprep")
  b22fa62a35d7 ("io_uring: apply worker limits to previous users")

from Linus' tree and commit:

  d475a9a6226c ("io_uring: inline hot path of __io_queue_sqe()")
  c072481ded14 ("io_uring: mark cold functions")

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 bc18af5e0a93,c2176bf339e0..000000000000
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@@ -6947,7 -6906,33 +6903,33 @@@ static void io_queue_linked_timeout(str
  	io_put_req(req);
  }
  
- static void __io_queue_sqe(struct io_kiocb *req)
+ static void io_queue_sqe_arm_apoll(struct io_kiocb *req)
+ 	__must_hold(&req->ctx->uring_lock)
+ {
+ 	struct io_kiocb *linked_timeout = io_prep_linked_timeout(req);
+ 
+ 	switch (io_arm_poll_handler(req)) {
+ 	case IO_APOLL_READY:
+ 		if (linked_timeout) {
 -			io_unprep_linked_timeout(req);
++			io_queue_linked_timeout(linked_timeout);
+ 			linked_timeout = NULL;
+ 		}
+ 		io_req_task_queue(req);
+ 		break;
+ 	case IO_APOLL_ABORTED:
+ 		/*
+ 		 * Queued up for async execution, worker will release
+ 		 * submit reference when the iocb is actually submitted.
+ 		 */
+ 		io_queue_async_work(req, NULL);
+ 		break;
+ 	}
+ 
+ 	if (linked_timeout)
+ 		io_queue_linked_timeout(linked_timeout);
+ }
+ 
+ static inline void __io_queue_sqe(struct io_kiocb *req)
  	__must_hold(&req->ctx->uring_lock)
  {
  	struct io_kiocb *linked_timeout;
@@@ -10647,11 -10690,9 +10696,11 @@@ static __cold int io_unregister_iowq_af
  	return io_wq_cpu_affinity(tctx->io_wq, NULL);
  }
  
- static int io_register_iowq_max_workers(struct io_ring_ctx *ctx,
- 					void __user *arg)
+ static __cold int io_register_iowq_max_workers(struct io_ring_ctx *ctx,
+ 					       void __user *arg)
 +	__must_hold(&ctx->uring_lock)
  {
 +	struct io_tctx_node *node;
  	struct io_uring_task *tctx = NULL;
  	struct io_sq_data *sqd = NULL;
  	__u32 new_count[2];

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Tejun Heo]

On Tue, Aug 17, 2021 at 06:50:20PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 17, 2021 at 06:40:07AM -1000, Tejun Heo wrote:
> > Ah, that probably isn't the right resolution. The seq_get_buf change needs
> > to be applied to the original mq-deadline.c file. Jens, how do you wanna
> > proceed?
> 
> Unless I'm missing something the pd_stat_fn that is affected was purely
> in the cgroup addition, so this resolution looks fine to me.

Ah, you're right.

Thank you.

-- 
tejun

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

[Christoph Hellwig]

On Tue, Aug 17, 2021 at 06:40:07AM -1000, Tejun Heo wrote:
> Ah, that probably isn't the right resolution. The seq_get_buf change needs
> to be applied to the original mq-deadline.c file. Jens, how do you wanna
> proceed?

Unless I'm missing something the pd_stat_fn that is affected was purely
in the cgroup addition, so this resolution looks fine to me.

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

[Tejun Heo]

On Tue, Aug 17, 2021 at 03:25:47PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/mq-deadline-cgroup.c
> 
> between commit:
> 
>   0f7839955114 ("Revert "block/mq-deadline: Add cgroup support"")
> 
> from Linus' tree and commit:
> 
>   252c651a4c85 ("blk-cgroup: stop using seq_get_buf")
> 
> from the block tree.
> 
> I fixed it up (I just removed the file) 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.

Ah, that probably isn't the right resolution. The seq_get_buf change needs
to be applied to the original mq-deadline.c file. Jens, how do you wanna
proceed?

Thanks.

-- 
tejun

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Hi all,

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

  block/mq-deadline-cgroup.c

between commit:

  0f7839955114 ("Revert "block/mq-deadline: Add cgroup support"")

from Linus' tree and commit:

  252c651a4c85 ("blk-cgroup: stop using seq_get_buf")

from the block tree.

I fixed it up (I just removed the file) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jens Axboe]

On 8/8/21 10:29 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/io-wq.c
> 
> between commit:
> 
>   21698274da5b ("io-wq: fix lack of acct->nr_workers < acct->max_workers judgement")
> 
> from Linus' tree and commit:
> 
>   e16aa0c614c6 ("io-wq: remove GFP_ATOMIC allocation off schedule out path")
> 
> from the block tree.
> 
> I fixed it up (I just used the latter version, but more may be needed?) 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'm going to re-shuffle the 5.15 branch, I knew we'd be hitting this
conflict after the merge for 5.14 on Saturday. Hence it'll be a short
lived conflict.

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Hi all,

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

  fs/io-wq.c

between commit:

  21698274da5b ("io-wq: fix lack of acct->nr_workers < acct->max_workers judgement")

from Linus' tree and commit:

  e16aa0c614c6 ("io-wq: remove GFP_ATOMIC allocation off schedule out path")

from the block tree.

I fixed it up (I just used the latter version, but more may be needed?) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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..000000000000
--- 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 = &req->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 = &req->io->rw.iter;
+ 	if (rw)
+ 		iter = &rw->iter;
  
  	ret = io_import_iovec(READ, req, &iovec, 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 */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jens Axboe]

On 1/27/20 5:38 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/io_uring.c
> 
> between commit:
> 
>   73e08e711d9c ("Revert "io_uring: only allow submit from owning task"")
> 
> from Linus' tree and commit:
> 
>   9ef4f124894b ("io_uring: clamp to_submit in io_submit_sqes()")
> 
> 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, looks good to me. I'll try cooperating better with myself ;-)

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Hi all,

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

  fs/io_uring.c

between commit:

  73e08e711d9c ("Revert "io_uring: only allow submit from owning task"")

from Linus' tree and commit:

  9ef4f124894b ("io_uring: clamp to_submit in io_submit_sqes()")

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 e54556b0fcc6,82fd87e3a6ca..000000000000
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@@ -5157,7 -6384,12 +6380,6 @@@ SYSCALL_DEFINE6(io_uring_enter, unsigne
  	} else if (to_submit) {
  		struct mm_struct *cur_mm;
  
- 		to_submit = min(to_submit, ctx->sq_entries);
 -		if (current->mm != ctx->sqo_mm ||
 -		    current_cred() != ctx->creds) {
 -			ret = -EPERM;
 -			goto out;
 -		}
 -
  		mutex_lock(&ctx->uring_lock);
  		/* already have mm, so io_submit_sqes() won't try to grab it */
  		cur_mm = ctx->sqo_mm;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

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..000000000000
--- 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 = &iter_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;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

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..000000000000
--- 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 int		ki_cookie; /* for ->iopoll */
 -} __randomize_layout;
 +
 +	randomized_struct_fields_end
 +};
  
  static inline bool is_sync_kiocb(struct kiocb *kiocb)
  {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

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..000000000000
--- 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
   */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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..000000000000
--- 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(&bio);
 +
  	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..000000000000
--- 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 = &bio_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..000000000000
--- 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(&io->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 <axboe@kernel.dk> wrote:
>>
>> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe <axboe@kernel.dk> 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 <axboe@kernel.dk> wrote:
>
> On 06/22/2017 09:24 PM, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > On Thu, 22 Jun 2017 21:09:22 -0600 Jens Axboe <axboe@kernel.dk> 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 <axboe@kernel.dk> 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 <axboe@kernel.dk> 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 <axboe@kernel.dk> 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

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..000000000000
--- 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, &hctx->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, &hctx->state))
 +			atomic_inc(&q->shared_hctx_restart);
 +	} else
 +		set_bit(BLK_MQ_S_SCHED_RESTART, &hctx->state);
 +}
 +
 +static bool blk_mq_sched_restart_hctx(struct blk_mq_hw_ctx *hctx)
 +{
 +	if (!test_bit(BLK_MQ_S_SCHED_RESTART, &hctx->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, &hctx->state))
 +			atomic_dec(&q->shared_hctx_restart);
 +	} else
 +		clear_bit(BLK_MQ_S_SCHED_RESTART, &hctx->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
- 		blk_mq_finish_request(rq);
- }
- 
  void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx)
  {
  	struct request_queue *q = hctx->queue;

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..000000000000
--- 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(&plug);
- 	ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+ 	ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
  			&bio);
  	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(&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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au> 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..000000000000
--- 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->dev, "blkfront_resume: %s\n", dev->nodename);
  
 +	bio_list_init(&info->bio_list);
 +	INIT_LIST_HEAD(&info->requests);
 +	for (i = 0; i < info->nr_rings; i++) {
 +		struct blkfront_ring_info *rinfo = &info->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(&shadow[j].request->queuelist, &info->requests);
 +				continue;
 +			}
 +			merge_bio.head = shadow[j].request->bio;
 +			merge_bio.tail = shadow[j].request->biotail;
 +			bio_list_merge(&info->bio_list, &merge_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..000000000000
--- 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(&plug);
- 	ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+ 	ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
  			&bio);
  	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(&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

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..000000000000
--- 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, &dev->flags))
++	if (dev->ctrl.state != NVME_CTRL_DELETING)
 +		goto out;
 +
- 	set_bit(NVME_CTRL_RESETTING, &dev->flags);
+ 	if (!nvme_change_ctrl_state(&dev->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, &dev->flags);
 -	del_timer_sync(&dev->watchdog_timer);
 -
+ 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
+ 
  	pci_set_drvdata(pdev, NULL);
- 	flush_work(&dev->async_work);
 +	flush_work(&dev->reset_work);
- 	flush_work(&dev->scan_work);
- 	nvme_remove_namespaces(&dev->ctrl);
  	nvme_uninit_ctrl(&dev->ctrl);
  	nvme_dev_disable(dev, true);
  	flush_work(&dev->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..000000000000
--- 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, &ns->flags)) {
 +		set_capacity(disk, 0);
 +		return -ENODEV;
 +	}
  	if (nvme_identify_ns(ns->ctrl, ns->ns_id, &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(&ctrl->namespaces_mutex);
  	list_for_each_entry_safe(ns, next, &ctrl->namespaces, list)
  		nvme_ns_remove(ns);
 -	mutex_unlock(&ctrl->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(&ctrl->ns_ida);
  
  	spin_lock(&dev_list_lock);
  	list_add_tail(&ctrl->node, &nvme_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(&ctrl->namespaces_mutex);
 +	list_for_each_entry(ns, &ctrl->namespaces, list) {
 +		if (!kref_get_unless_zero(&ns->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, &ns->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(&ctrl->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..000000000000
--- 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, &dev->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(&dev->tagset))
  			return 0;
  		dev->ctrl.tagset = &dev->tagset;
+ 	} else {
+ 		blk_mq_update_nr_hw_queues(&dev->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, &dev->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(&dev->watchdog_timer);
  
  	mutex_lock(&dev->shutdown_lock);
 -	if (dev->bar) {
 +	if (pci_is_enabled(to_pci_dev(dev->dev))) {
  		nvme_stop_queues(&dev->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, &dev->async_work);
  
- 	result = nvme_dev_list_add(dev);
- 	if (result)
- 		goto out;
+ 	mod_timer(&dev->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(&pdev->dev);
  	pci_set_drvdata(pdev, dev);
  
 +	result = nvme_dev_map(dev);
 +	if (result)
 +		goto free;
 +
- 	INIT_LIST_HEAD(&dev->node);
  	INIT_WORK(&dev->scan_work, nvme_dev_scan);
  	INIT_WORK(&dev->reset_work, nvme_reset_work);
  	INIT_WORK(&dev->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, &dev->flags);
+ 	del_timer_sync(&dev->watchdog_timer);
+ 
  	pci_set_drvdata(pdev, NULL);
+ 	flush_work(&dev->async_work);
 -	flush_work(&dev->reset_work);
  	flush_work(&dev->scan_work);
  	nvme_remove_namespaces(&dev->ctrl);
  	nvme_uninit_ctrl(&dev->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..000000000000
--- 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(&dev->watchdog_timer);
+ 
  	pci_set_drvdata(pdev, NULL);
+ 	flush_work(&dev->async_work);
 -	flush_work(&dev->reset_work);
  	flush_work(&dev->scan_work);
  	nvme_remove_namespaces(&dev->ctrl);
  	nvme_uninit_ctrl(&dev->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..000000000000
--- 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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
>> Date: Thu, 31 Dec 2015 14:21:38 +1100
>> Subject: [PATCH] nvme: merge fix up for ns code movement
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>   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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> Date: Thu, 31 Dec 2015 14:21:38 +1100
> Subject: [PATCH] nvme: merge fix up for ns code movement
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  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 Rothwell                    sfr@canb.auug.org.au

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/nvme/host/Makefile
index a5fe23952586,baf9f52bbfa5..000000000000
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@@ -1,5 -1,5 +1,6 @@@
  
  obj-$(CONFIG_BLK_DEV_NVME)     += nvme.o
  
- lightnvm-$(CONFIG_NVM)	:= lightnvm.o
- nvme-y		+= pci.o scsi.o $(lightnvm-y)
 -nvme-y					+= core.o pci.o lightnvm.o
++lightnvm-$(CONFIG_NVM)			:= lightnvm.o
++nvme-y					+= core.o pci.o $(lightnvm-y)
+ nvme-$(CONFIG_BLK_DEV_NVME_SCSI)        += scsi.o

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 <sfr@canb.auug.org.au>
Date: Thu, 31 Dec 2015 14:21:38 +1100
Subject: [PATCH] nvme: merge fix up for ns code movement

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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 Rothwell                    sfr@canb.auug.org.au

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/nvme/host/lightnvm.c
index 15f2acb4d5cd,09cf0b99d2fa..000000000000
--- 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 *)&c, 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;
  

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/nvme/host/pci.c
index 9e294ff4e652,a64d0baacc58..000000000000
--- 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(&dev->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(&dev->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;

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/nvme/host/Makefile
index a5fe23952586,3e26dc921c38..000000000000
--- 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)

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/block/loop.c
index 674f800a3b57,23376084a5cb..000000000000
--- 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->lo_lock);
-  repeat:
- 	list_splice_init(&lo->write_cmd_head, &cmd_list);
- 	spin_unlock_irq(&lo->lo_lock);
- 
- 	while (!list_empty(&cmd_list)) {
- 		struct loop_cmd *cmd = list_first_entry(&cmd_list,
- 				struct loop_cmd, list);
- 		list_del_init(&cmd->list);
- 		loop_handle_cmd(cmd);
- 	}
- 
- 	spin_lock_irq(&lo->lo_lock);
- 	if (!list_empty(&lo->write_cmd_head))
- 		goto repeat;
- 	lo->write_started = false;
- 	spin_unlock_irq(&lo->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);
  }

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 Rothwell                    sfr@canb.auug.org.au

diff --cc fs/fs-writeback.c
index ae0f438c2ee6,f4f0f228a530..000000000000
--- 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);
  	}
  }

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 Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc mm/backing-dev.c
index 000e7b3b9896,887d72a85b5e..000000000000
--- 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);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/block/nvme-core.c
index 683dff272562,513908ff46c4..000000000000
--- 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;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc mm/page-writeback.c
index eb59f7eea508,e1514d5b4e9b..000000000000
--- 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_thresh                    thresh - bdi_thresh
- 	 * span = ---------- * (8 * write_bw) + ------------------- * bdi_thresh
- 	 *          thresh                            thresh
+ 	 *        wb_thresh                    thresh - 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;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/blkdev.h
index 5d93a6645e88,31cd832cebb7..000000000000
--- 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);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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 <sfr@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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/dm.c
index 2caf492890d6,38837f8ea327..000000000000
--- 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) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

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 <sfr@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 <sfr@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 Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

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).

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/raid5.c between commit 37c61ff31e9b ("raid5: set bio bi_vcnt 0
for discard request") from Linus' tree and commit ed2d2f9a8265 ("block:
Abstract out bvec iterator") from the block tree.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/raid5.c
index f8b906843926,e00beb5d2e88..000000000000
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@@ -777,13 -777,7 +777,13 @@@ static void ops_run_io(struct stripe_he
  			bi->bi_vcnt = 1;
  			bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
  			bi->bi_io_vec[0].bv_offset = 0;
- 			bi->bi_size = STRIPE_SIZE;
+ 			bi->bi_iter.bi_size = STRIPE_SIZE;
 +			/*
 +			 * If this is discard request, set bi_vcnt 0. We don't
 +			 * want to confuse SCSI because SCSI will replace payload
 +			 */
 +			if (rw & REQ_DISCARD)
 +				bi->bi_vcnt = 0;
  			if (rrdev)
  				set_bit(R5_DOUBLE_LOCKED, &sh->dev[i].flags);
  
@@@ -821,13 -815,7 +821,13 @@@
  			rbi->bi_vcnt = 1;
  			rbi->bi_io_vec[0].bv_len = STRIPE_SIZE;
  			rbi->bi_io_vec[0].bv_offset = 0;
- 			rbi->bi_size = STRIPE_SIZE;
+ 			rbi->bi_iter.bi_size = STRIPE_SIZE;
 +			/*
 +			 * If this is discard request, set bi_vcnt 0. We don't
 +			 * want to confuse SCSI because SCSI will replace payload
 +			 */
 +			if (rw & REQ_DISCARD)
 +				rbi->bi_vcnt = 0;
  			if (conf->mddev->gendisk)
  				trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
  						      rbi, disk_devt(conf->mddev->gendisk),

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/bcache/request.c between commit c0f04d88e46d ("bcache: Fix
flushes in writeback mode") from Linus' tree and commit 53027147e43c
("bcache: Prune struct btree_op") and dd879364df83 ("bcache: Break up struct search") from the block tree.

I fixed it up (I wasn't sure, but I used the version from Linus' tree -
see below) and can carry the fix as necessary (no action is required).

There were several other patches that affect this area that were commited
directly to Linus' tree today ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/bcache/request.c
index 71eb233,231b108..0000000
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@@ -979,68 -1059,52 +1059,55 @@@ static void cached_dev_write(struct cac
  
  	if (should_writeback(dc, s->orig_bio,
  			     cache_mode(dc, bio),
- 			     s->op.skip)) {
- 		s->op.skip = false;
- 		s->writeback = true;
+ 			     s->iop.bypass)) {
+ 		s->iop.bypass = false;
+ 		s->iop.writeback = true;
  	}
  
- 	if (s->op.skip)
- 		goto skip;
- 
- 	trace_bcache_write(s->orig_bio, s->writeback, s->op.skip);
+ 	if (s->iop.bypass) {
+ 		s->iop.bio = s->orig_bio;
+ 		bio_get(s->iop.bio);
  
- 	if (!s->writeback) {
- 		s->op.cache_bio = bio_clone_bioset(bio, GFP_NOIO,
- 						   dc->disk.bio_split);
- 
- 		closure_bio_submit(bio, cl, s->d);
- 	} else {
+ 		if (!(bio->bi_rw & REQ_DISCARD) ||
+ 		    blk_queue_discard(bdev_get_queue(dc->bdev)))
+ 			closure_bio_submit(bio, cl, s->d);
+ 	} else if (s->iop.writeback) {
  		bch_writeback_add(dc);
  
 -		if (s->iop.flush_journal) {
 +		if (bio->bi_rw & REQ_FLUSH) {
  			/* Also need to send a flush to the backing device */
 -			s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
 -						      dc->disk.bio_split);
 +			struct bio *flush = bio_alloc_bioset(0, GFP_NOIO,
 +							     dc->disk.bio_split);
  
 -			bio->bi_size = 0;
 -			bio->bi_vcnt = 0;
 -			closure_bio_submit(bio, cl, s->d);
 +			flush->bi_rw	= WRITE_FLUSH;
 +			flush->bi_bdev	= bio->bi_bdev;
 +			flush->bi_end_io = request_endio;
 +			flush->bi_private = cl;
 +
 +			closure_bio_submit(flush, cl, s->d);
  		} else {
- 			s->op.cache_bio = bio;
+ 			s->iop.bio = bio;
  		}
- 	}
- out:
- 	closure_call(&s->op.cl, bch_insert_data, NULL, cl);
- 	continue_at(cl, cached_dev_write_complete, NULL);
- skip:
- 	s->op.skip = true;
- 	s->op.cache_bio = s->orig_bio;
- 	bio_get(s->op.cache_bio);
+ 	} else {
+ 		s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
+ 					      dc->disk.bio_split);
  
- 	if ((bio->bi_rw & REQ_DISCARD) &&
- 	    !blk_queue_discard(bdev_get_queue(dc->bdev)))
- 		goto out;
+ 		closure_bio_submit(bio, cl, s->d);
+ 	}
  
- 	closure_bio_submit(bio, cl, s->d);
- 	goto out;
+ 	closure_call(&s->iop.cl, bch_data_insert, NULL, cl);
+ 	continue_at(cl, cached_dev_write_complete, NULL);
  }
  
- static void request_nodata(struct cached_dev *dc, struct search *s)
+ static void cached_dev_nodata(struct closure *cl)
  {
- 	struct closure *cl = &s->cl;
+ 	struct search *s = container_of(cl, struct search, cl);
  	struct bio *bio = &s->bio.bio;
  
- 	if (bio->bi_rw & REQ_DISCARD) {
- 		request_write(dc, s);
- 		return;
- 	}
- 
- 	if (s->op.flush_journal)
- 		bch_journal_meta(s->op.c, cl);
+ 	if (s->iop.flush_journal)
+ 		bch_journal_meta(s->iop.c, cl);
  
+ 	/* If it's a flush, we send the flush to the backing device too */
  	closure_bio_submit(bio, cl, s->d);
  
  	continue_at(cl, cached_dev_bio_complete, NULL);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
include/linux/blk_types.h between commit 713685111774 ("mm: make
snapshotting pages for stable writes a per-bio operation") from the  tree
and commit a38352e0ac02 ("block: Add an explicit bio flag for bios that
own their bvec") from the block tree.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/blk_types.h
index 22990cf,e8de670..0000000
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@@ -117,7 -116,8 +117,8 @@@ struct bio 
   * Flags starting here get preserved by bio_reset() - this includes
   * BIO_POOL_IDX()
   */
 -#define BIO_RESET_BITS	12
 -#define BIO_OWNS_VEC	12	/* bio_free() should free bvec */
 +#define BIO_RESET_BITS	13
++#define BIO_OWNS_VEC	13	/* bio_free() should free bvec */
  
  #define bio_flagged(bio, flag)	((bio)->bi_flags & (1 << (flag)))
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/raid5.c between commit e3620a3ad526 ("MD RAID5: Avoid
accessing gendisk or queue structs when not available") from Linus' tree
and commit 2f6db2a70734 ("raid5: use bio_reset()") from the block tree.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/raid5.c
index 24909eb,7bbd285..0000000
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@@ -666,16 -665,11 +665,13 @@@ static void ops_run_io(struct stripe_he
  			bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
  			bi->bi_io_vec[0].bv_offset = 0;
  			bi->bi_size = STRIPE_SIZE;
- 			bi->bi_next = NULL;
  			if (rrdev)
  				set_bit(R5_DOUBLE_LOCKED, &sh->dev[i].flags);
 -			trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
 -					      bi, disk_devt(conf->mddev->gendisk),
 -					      sh->dev[i].sector);
 +
 +			if (conf->mddev->gendisk)
 +				trace_block_bio_remap(bdev_get_queue(bi->bi_bdev),
 +						      bi, disk_devt(conf->mddev->gendisk),
 +						      sh->dev[i].sector);
  			generic_make_request(bi);
  		}
  		if (rrdev) {
@@@ -700,13 -700,9 +702,10 @@@
  			rbi->bi_io_vec[0].bv_len = STRIPE_SIZE;
  			rbi->bi_io_vec[0].bv_offset = 0;
  			rbi->bi_size = STRIPE_SIZE;
- 			rbi->bi_next = NULL;
 -			trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
 -					      rbi, disk_devt(conf->mddev->gendisk),
 -					      sh->dev[i].sector);
 +			if (conf->mddev->gendisk)
 +				trace_block_bio_remap(bdev_get_queue(rbi->bi_bdev),
 +						      rbi, disk_devt(conf->mddev->gendisk),
 +						      sh->dev[i].sector);
  			generic_make_request(rbi);
  		}
  		if (!rdev && !rrdev) {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
block/blk-exec.c between commit 893d290f1d74 ("block: Don't access
request after it might be freed") from Linus' tree and commit
c246e80d8673 ("block: Avoid that request_fn is invoked on a dead queue")
from the block tree.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc block/blk-exec.c
index f71eac3,1320e74..0000000
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@@ -77,8 -71,8 +77,8 @@@ void blk_execute_rq_nowait(struct reque
  	__elv_add_request(q, rq, where);
  	__blk_run_queue(q);
  	/* the queue is stopped so it won't be run */
 -	if (rq->cmd_type == REQ_TYPE_PM_RESUME)
 +	if (is_pm_resume)
- 		q->request_fn(q);
+ 		__blk_run_queue_uncond(q);
  	spin_unlock_irq(q->queue_lock);
  }
  EXPORT_SYMBOL_GPL(blk_execute_rq_nowait);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Herton Ronaldo Krzesinski]

On Wed, Oct 31, 2012 at 01:55:14PM +0000, Ben Hutchings wrote:
> On Wed, 2012-10-31 at 13:04 +1100, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > Today's linux-next merge of the block tree got a conflict in
> > drivers/block/floppy.c between a set of common patches from Linus' tree
> > and commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
> > not been registered") from the block tree.
> > 
> > I fixed it up (by using the block tree version) and can carry the fix as
> > necessary (no action is required).
> 
> commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
> not been registered") was supposed to be dropped or reverted; I don't
> why it's hanging around.

I also don't feel inclined to continue to fiddle too much with the
floppy driver, but may be we should add to it a fix to not leak the
reference to disks[]->queue in the error handling, checking if we really
did the add_disk (the "disks[drive]->queue = NULL;" under out_put_disk).

> 
> Ben.
> 
> -- 
> Ben Hutchings
> I'm always amazed by the number of people who take up solipsism because
> they heard someone else explain it. - E*Borg on alt.fan.pratchett

-- 
[]'s
Herton

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

[Jens Axboe]

On 2012-10-31 14:55, Ben Hutchings wrote:
> On Wed, 2012-10-31 at 13:04 +1100, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> Today's linux-next merge of the block tree got a conflict in
>> drivers/block/floppy.c between a set of common patches from Linus' tree
>> and commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
>> not been registered") from the block tree.
>>
>> I fixed it up (by using the block tree version) and can carry the fix as
>> necessary (no action is required).
> 
> commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
> not been registered") was supposed to be dropped or reverted; I don't
> why it's hanging around.

It's my for-next branch that wasn't updated yet. Will do that now.

-- 
Jens Axboe

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Wed, 2012-10-31 at 13:04 +1100, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> drivers/block/floppy.c between a set of common patches from Linus' tree
> and commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
> not been registered") from the block tree.
> 
> I fixed it up (by using the block tree version) and can carry the fix as
> necessary (no action is required).

commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
not been registered") was supposed to be dropped or reverted; I don't
why it's hanging around.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/block/floppy.c between a set of common patches from Linus' tree
and commit b33d002f4b6b ("genhd: Make put_disk() safe for disks that have
not been registered") from the block tree.

I fixed it up (by using the block tree version) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hi Jens,

On Tue, 01 Nov 2011 09:09:45 +0100 Jens Axboe <axboe@kernel.dk> wrote:
>
> Fixup looks good, however don't you get the same conflict in basically
> all the raid personalities? Fixup is indeed just the simple int -> void
> transition, conflict is because of the mddev_t -> struct mddev change
> that is now in Linus' tree.

I got these conflicts in all the raid personalities a while ago.  I am
not sure why this turned up for just raid10 again.

> I'll push my pending off to Linus today or tomorrow, so this will be
> resolved shortly.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Jens Axboe]

On 2011-11-01 06:15, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> drivers/md/raid10.c between commit fd01b88c75a7 ("md: remove typedefs:
> mddev_t -> struct mddev") from Linus' tree and commit 5a7bbad27a41
> ("block: remove support for bio remapping from ->make_request") from the
> block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Fixup looks good, however don't you get the same conflict in basically
all the raid personalities? Fixup is indeed just the simple int -> void
transition, conflict is because of the mddev_t -> struct mddev change
that is now in Linus' tree.

I'll push my pending off to Linus today or tomorrow, so this will be
resolved shortly.

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/raid10.c between commit fd01b88c75a7 ("md: remove typedefs:
mddev_t -> struct mddev") from Linus' tree and commit 5a7bbad27a41
("block: remove support for bio remapping from ->make_request") from the
block tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/raid10.c
index c025a82,ea5fc0b..0000000
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@@ -842,11 -830,11 +842,11 @@@ static void unfreeze_array(struct r10co
  	spin_unlock_irq(&conf->resync_lock);
  }
  
- static int make_request(struct mddev *mddev, struct bio * bio)
 -static void make_request(mddev_t *mddev, struct bio * bio)
++static void make_request(struct mddev *mddev, struct bio * bio)
  {
 -	conf_t *conf = mddev->private;
 -	mirror_info_t *mirror;
 -	r10bio_t *r10_bio;
 +	struct r10conf *conf = mddev->private;
 +	struct mirror_info *mirror;
 +	struct r10bio *r10_bio;
  	struct bio *read_bio;
  	int i;
  	int chunk_sects = conf->chunk_mask + 1;
@@@ -1176,12 -1156,11 +1174,11 @@@ retry_write
  
  	if (do_sync || !mddev->bitmap || !plugged)
  		md_wakeup_thread(mddev->thread);
- 	return 0;
  }
  
 -static void status(struct seq_file *seq, mddev_t *mddev)
 +static void status(struct seq_file *seq, struct mddev *mddev)
  {
 -	conf_t *conf = mddev->private;
 +	struct r10conf *conf = mddev->private;
  	int i;
  
  	if (conf->near_copies < conf->raid_disks)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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 conflicts in
drivers/block/paride/pcd.c and drivers/cdrom/viocd.c between commit
9fd097b14918 ("block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe
drivers") from Linus' tree and commit d4dc210f69bc ("block: don't block
events on excl write for non-optical devices") from the block tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/block/paride/pcd.c
index 8690e31,a0aabd9..0000000
--- a/drivers/block/paride/pcd.c
+++ b/drivers/block/paride/pcd.c
@@@ -320,6 -320,8 +320,7 @@@ static void pcd_init_units(void
  		disk->first_minor = unit;
  		strcpy(disk->disk_name, cd->name);	/* umm... */
  		disk->fops = &pcd_bdops;
+ 		disk->flags = GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE;
 -		disk->events = DISK_EVENT_MEDIA_CHANGE;
  	}
  }
  
diff --cc drivers/cdrom/viocd.c
index e427fbe,ae15a4d..0000000
--- a/drivers/cdrom/viocd.c
+++ b/drivers/cdrom/viocd.c
@@@ -625,7 -625,9 +625,8 @@@ static int viocd_probe(struct vio_dev *
  	blk_queue_max_hw_sectors(q, 4096 / 512);
  	gendisk->queue = q;
  	gendisk->fops = &viocd_fops;
- 	gendisk->flags = GENHD_FL_CD|GENHD_FL_REMOVABLE;
+ 	gendisk->flags = GENHD_FL_CD | GENHD_FL_REMOVABLE |
+ 			 GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE;
 -	gendisk->events = DISK_EVENT_MEDIA_CHANGE;
  	set_capacity(gendisk, 0);
  	gendisk->private_data = d;
  	d->viocd_disk = gendisk;

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

[Jens Axboe]

On 2011-03-21 01:43, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in fs/super.c
> between commit 9d412a43c3b2 ("vfs: split off vfsmount-related parts of
> vfs_kern_mount()") from Linus' tree and commit 95f28604a65b ("fs: assign
> sb->s_bdi to default_backing_dev_info if the bdi is going away") from the
> block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Thanks Stephen, your fixup is (obviously) correct.

-- 
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 fs/super.c
between commit 9d412a43c3b2 ("vfs: split off vfsmount-related parts of
vfs_kern_mount()") from Linus' tree and commit 95f28604a65b ("fs: assign
sb->s_bdi to default_backing_dev_info if the bdi is going away") from the
block tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/super.c
index e848649,0d89e93..0000000
--- a/fs/super.c
+++ b/fs/super.c
@@@ -928,17 -989,25 +929,18 @@@ mount_fs(struct file_system_type *type
  			goto out_free_secdata;
  	}
  
 -	if (type->mount) {
 -		root = type->mount(type, flags, name, data);
 -		if (IS_ERR(root)) {
 -			error = PTR_ERR(root);
 -			goto out_free_secdata;
 -		}
 -		mnt->mnt_root = root;
 -		mnt->mnt_sb = root->d_sb;
 -	} else {
 -		error = type->get_sb(type, flags, name, data, mnt);
 -		if (error < 0)
 -			goto out_free_secdata;
 +	root = type->mount(type, flags, name, data);
 +	if (IS_ERR(root)) {
 +		error = PTR_ERR(root);
 +		goto out_free_secdata;
  	}
 -	BUG_ON(!mnt->mnt_sb);
 -	WARN_ON(!mnt->mnt_sb->s_bdi);
 -	WARN_ON(mnt->mnt_sb->s_bdi == &default_backing_dev_info);
 -	mnt->mnt_sb->s_flags |= MS_BORN;
 +	sb = root->d_sb;
 +	BUG_ON(!sb);
 +	WARN_ON(!sb->s_bdi);
++	WARN_ON(sb->s_bdi == &default_backing_dev_info);
 +	sb->s_flags |= MS_BORN;
  
 -	error = security_sb_kern_mount(mnt->mnt_sb, flags, secdata);
 +	error = security_sb_kern_mount(sb, flags, secdata);
  	if (error)
  		goto out_sb;
  

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

[Sedat Dilek]

Thanks, I will wait till tommorrow with a new build of linux-next
(looks like this is one of this "manic mondays" and... more coffee).

Just looked in the meantime trough WildWildWeb and found a new
tig-0.17 which I could built successfully against ncurses-5.8 and this
was more important.

- Sedat -

On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-03-07 12:35, Sedat Dilek wrote:
>> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>>> On 2011-03-07 12:25, Sedat Dilek wrote:
>>>> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>>>>> On 2011-03-07 12:14, Sedat Dilek wrote:
>>>>>> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>>>>>>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>>>>>>> $ git log -1 | cat
>>>>>>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>>>>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>>>>>>
>>>>>>>>     Add linux-next specific files for 20110307
>>>>>>>>
>>>>>>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>>
>>>>>>>> $ git pull
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>>>>>>> for-next
>>>>>>>> remote: Counting objects: 158, done.
>>>>>>>> remote: Compressing objects: 100% (89/89), done.
>>>>>>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>>>>>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>>>>>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>>>>>>> From
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>>>>>>  * branch            for-next   -> FETCH_HEAD
>>>>>>>> warning: too many files (created: 1120 deleted: 637), skipping
>>>>>>>> inexact
>>>>>>>> rename detection
>>>>>>>> warning: too many files (created: 974 deleted: 462), skipping
>>>>>>>> inexact
>>>>>>>> rename detection
>>>>>>>> Auto-merging block/blk-core.c
>>>>>>>> Auto-merging block/blk-flush.c
>>>>>>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>>>>>>> Auto-merging block/cfq-iosched.c
>>>>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>>>>>
>>>>>>> Ummm... don't those conflicts come from Stephen's commits?  You would
>>>>>>> need to revert the merge and fixup commits and then pull in the block
>>>>>>> branch.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> --
>>>>>>> tejun
>>>>>>>
>>>>>>
>>>>>> I have reverted the merge-fix from Stephen "[PATCH] block: update for
>>>>>> __blk_run_queue() API update" which changed block/blk-flush.c, this
>>>>>> remains:
>>>>>> ...
>>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>>>
>>>>>> As it is 12p.m. and sun shining, my decision and direction is clear:
>>>>>> Lunch + City.
>>>>>
>>>>> Just checked here, I can pull my for-next cleanly into Linus' master.
>>>>> What is the block tree for-next branch sha?
>>>>>
>>>>> --
>>>>> Jens Axboe
>>>>>
>>>>>
>>>>
>>>> No, I tried to merge your for-next into linux-next (which will happen
>>>> with tomorrows linux-next).
>>>>
>>>> [ linux-2.6-block.git#for-next ]
>>>> commit b873c5d692d4d5453cceed18bb06c62bb1a73ac0
>>>> "Merge branch 'block-for-2.6.39-core' of
>>>> ssh:///linux/kernel/git/tj/misc into for-2.6.39/core"
>>>
>>> linux-next should not have any CFQ changes that don't come from for-next
>>> from the linux block tree. Are you pulling it into a linux-next that
>>> already have some of the block changes?
>>>
>>> --
>>> Jens Axboe
>>>
>>>
>>
>> I have reverted the manual merge-fix from Stephen as pointed out by Tejun.
>>
>> As tig (utility) is broken with ncurses-5.8 in Debian/sid I currently
>> can't look through the commits.
>> So, I can't say if there were further modifications by merging block
>> stuff into linux-next.
>> I have added the last 5 commits to block/cfq-iosched.c as TXT.
>
> OK, I see Stephen already pointed out where things have gone wrong. I
> try to ensure that it'll merge into Linus' git cleanly, so I know that
> Stephen wont run into problems. Sometimes things will get fast tracked
> into Linus' git and I don't update for-next in time, that's when
> problems arise.
>
> linux-next is a new tree everyday, you can't pull from it like you would
> other development trees.
>
> --
> Jens Axboe
>
>

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

[Jens Axboe]

On 2011-03-07 12:35, Sedat Dilek wrote:
> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2011-03-07 12:25, Sedat Dilek wrote:
>>> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>>>> On 2011-03-07 12:14, Sedat Dilek wrote:
>>>>> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>>>>>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>>>>>> $ git log -1 | cat
>>>>>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>>>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>>>>>
>>>>>>>     Add linux-next specific files for 20110307
>>>>>>>
>>>>>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>
>>>>>>> $ git pull
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>>>>>> for-next
>>>>>>> remote: Counting objects: 158, done.
>>>>>>> remote: Compressing objects: 100% (89/89), done.
>>>>>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>>>>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>>>>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>>>>>> From
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>>>>>  * branch            for-next   -> FETCH_HEAD
>>>>>>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>>>>>>> rename detection
>>>>>>> warning: too many files (created: 974 deleted: 462), skipping inexact
>>>>>>> rename detection
>>>>>>> Auto-merging block/blk-core.c
>>>>>>> Auto-merging block/blk-flush.c
>>>>>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>>>>>> Auto-merging block/cfq-iosched.c
>>>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>>>>
>>>>>> Ummm... don't those conflicts come from Stephen's commits?  You would
>>>>>> need to revert the merge and fixup commits and then pull in the block
>>>>>> branch.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> tejun
>>>>>>
>>>>>
>>>>> I have reverted the merge-fix from Stephen "[PATCH] block: update for
>>>>> __blk_run_queue() API update" which changed block/blk-flush.c, this
>>>>> remains:
>>>>> ...
>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>>
>>>>> As it is 12p.m. and sun shining, my decision and direction is clear:
>>>>> Lunch + City.
>>>>
>>>> Just checked here, I can pull my for-next cleanly into Linus' master.
>>>> What is the block tree for-next branch sha?
>>>>
>>>> --
>>>> Jens Axboe
>>>>
>>>>
>>>
>>> No, I tried to merge your for-next into linux-next (which will happen
>>> with tomorrows linux-next).
>>>
>>> [ linux-2.6-block.git#for-next ]
>>> commit b873c5d692d4d5453cceed18bb06c62bb1a73ac0
>>> "Merge branch 'block-for-2.6.39-core' of
>>> ssh:///linux/kernel/git/tj/misc into for-2.6.39/core"
>>
>> linux-next should not have any CFQ changes that don't come from for-next
>> from the linux block tree. Are you pulling it into a linux-next that
>> already have some of the block changes?
>>
>> --
>> Jens Axboe
>>
>>
> 
> I have reverted the manual merge-fix from Stephen as pointed out by Tejun.
> 
> As tig (utility) is broken with ncurses-5.8 in Debian/sid I currently
> can't look through the commits.
> So, I can't say if there were further modifications by merging block
> stuff into linux-next.
> I have added the last 5 commits to block/cfq-iosched.c as TXT.

OK, I see Stephen already pointed out where things have gone wrong. I
try to ensure that it'll merge into Linus' git cleanly, so I know that
Stephen wont run into problems. Sometimes things will get fast tracked
into Linus' git and I don't update for-next in time, that's when
problems arise.

linux-next is a new tree everyday, you can't pull from it like you would
other development trees.

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

Hi Sedat,

On Mon, 7 Mar 2011 12:25:23 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>
> No, I tried to merge your for-next into linux-next (which will happen
> with tomorrows linux-next).

No, it won't.  Each day I start with Linus' tree and merge all the other
trees.  Doing it the other way would lead to a real mess.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

Hi Jens,

On Mon, 07 Mar 2011 12:16:12 +0100 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 2011-03-07 12:14, Sedat Dilek wrote:
> > On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
> >> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
> >>> $ git log -1 | cat
> >>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
> >>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
> >>> Date:   Mon Mar 7 17:38:41 2011 +1100
> >>>
> >>>     Add linux-next specific files for 20110307
> >>>
> >>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >>>
> >>> $ git pull
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
> >>> for-next
> >>> remote: Counting objects: 158, done.
> >>> remote: Compressing objects: 100% (89/89), done.
> >>> remote: Total 106 (delta 87), reused 21 (delta 17)
> >>> Receiving objects: 100% (106/106), 23.33 KiB, done.
> >>> Resolving deltas: 100% (87/87), completed with 34 local objects.
> >>> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
> >>>  * branch            for-next   -> FETCH_HEAD
> >>> warning: too many files (created: 1120 deleted: 637), skipping inexact
> >>> rename detection
> >>> warning: too many files (created: 974 deleted: 462), skipping inexact
> >>> rename detection
> >>> Auto-merging block/blk-core.c
> >>> Auto-merging block/blk-flush.c
> >>> CONFLICT (content): Merge conflict in block/blk-flush.c
> >>> Auto-merging block/cfq-iosched.c
> >>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
> >>> Automatic merge failed; fix conflicts and then commit the result.
> >>
> >> Ummm... don't those conflicts come from Stephen's commits?  You would
> >> need to revert the merge and fixup commits and then pull in the block
> >> branch.
> > 
> > I have reverted the merge-fix from Stephen "[PATCH] block: update for
> > __blk_run_queue() API update" which changed block/blk-flush.c, this
> > remains:
> > ...
> > CONFLICT (content): Merge conflict in block/cfq-iosched.c

This is a different conflict that git resolved on its own.

> > As it is 12p.m. and sun shining, my decision and direction is clear:
> > Lunch + City.
> 
> Just checked here, I can pull my for-next cleanly into Linus' master.
> What is the block tree for-next branch sha?

This the correct test, trying to remerge a tree into linux-next is bound
to have some conflicts.

I will let you know tomorrow, but I expect no problems.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Sedat Dilek]

[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]

On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-03-07 12:25, Sedat Dilek wrote:
>> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>>> On 2011-03-07 12:14, Sedat Dilek wrote:
>>>> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>>>>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>>>>> $ git log -1 | cat
>>>>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>>>>
>>>>>>     Add linux-next specific files for 20110307
>>>>>>
>>>>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>
>>>>>> $ git pull
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>>>>> for-next
>>>>>> remote: Counting objects: 158, done.
>>>>>> remote: Compressing objects: 100% (89/89), done.
>>>>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>>>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>>>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>>>>> From
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>>>>  * branch            for-next   -> FETCH_HEAD
>>>>>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>>>>>> rename detection
>>>>>> warning: too many files (created: 974 deleted: 462), skipping inexact
>>>>>> rename detection
>>>>>> Auto-merging block/blk-core.c
>>>>>> Auto-merging block/blk-flush.c
>>>>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>>>>> Auto-merging block/cfq-iosched.c
>>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>>>
>>>>> Ummm... don't those conflicts come from Stephen's commits?  You would
>>>>> need to revert the merge and fixup commits and then pull in the block
>>>>> branch.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> tejun
>>>>>
>>>>
>>>> I have reverted the merge-fix from Stephen "[PATCH] block: update for
>>>> __blk_run_queue() API update" which changed block/blk-flush.c, this
>>>> remains:
>>>> ...
>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>
>>>> As it is 12p.m. and sun shining, my decision and direction is clear:
>>>> Lunch + City.
>>>
>>> Just checked here, I can pull my for-next cleanly into Linus' master.
>>> What is the block tree for-next branch sha?
>>>
>>> --
>>> Jens Axboe
>>>
>>>
>>
>> No, I tried to merge your for-next into linux-next (which will happen
>> with tomorrows linux-next).
>>
>> [ linux-2.6-block.git#for-next ]
>> commit b873c5d692d4d5453cceed18bb06c62bb1a73ac0
>> "Merge branch 'block-for-2.6.39-core' of
>> ssh:///linux/kernel/git/tj/misc into for-2.6.39/core"
>
> linux-next should not have any CFQ changes that don't come from for-next
> from the linux block tree. Are you pulling it into a linux-next that
> already have some of the block changes?
>
> --
> Jens Axboe
>
>

I have reverted the manual merge-fix from Stephen as pointed out by Tejun.

As tig (utility) is broken with ncurses-5.8 in Debian/sid I currently
can't look through the commits.
So, I can't say if there were further modifications by merging block
stuff into linux-next.
I have added the last 5 commits to block/cfq-iosched.c as TXT.

- Sedat -

[-- Attachment #2: last-5-commits-to-block_cfq-iosched-c.txt --]
[-- Type: text/plain, Size: 3521 bytes --]

commit feceaadd75c035ad2999b91266c4f3cd3c928d7d
Merge: 0c54ad0 763414b
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon Mar 7 13:19:47 2011 +1100

    Merge remote-tracking branch 'block/for-next'
    
    Conflicts:
    	block/blk-flush.c

commit 1654e7411a1ad4999fe7890ef51d2a2bbb1fcf76
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Mar 2 08:48:05 2011 -0500

    block: add @force_kblockd to __blk_run_queue()
    
    __blk_run_queue() automatically either calls q->request_fn() directly
    or schedules kblockd depending on whether the function is recursed.
    blk-flush implementation needs to be able to explicitly choose
    kblockd.  Add @force_kblockd.
    
    All the current users are converted to specify %false for the
    parameter and this patch doesn't introduce any behavior change.
    
    stable: This is prerequisite for fixing ide oops caused by the new
            blk-flush implementation.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Jan Beulich <JBeulich@novell.com>
    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: stable@kernel.org
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

commit 763414b132ab9d6f8e23657a87cc1dc823d1e34e
Merge: 6148a47 c186794
Author: Jens Axboe <jaxboe@fusionio.com>
Date:   Fri Feb 11 11:11:29 2011 +0100

    Merge branch 'for-2.6.39/core' into for-next
    
    Conflicts:
    	block/cfq-iosched.c
    
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

commit c186794dbb466b45cf40f942f2d09d6d5b4b0e42
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Feb 11 11:08:00 2011 +0100

    block: share request flush fields with  elevator_private
    
    Flush requests are never put on the IO scheduler.  Convert request
    structure's elevator_private* into an array and have the flush fields
    share a union with it.
    
    Reclaim the space lost in 'struct request' by moving 'completion_data'
    back in the union with 'rb_node'.
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

commit 02a8f01b5a9f396d0327977af4c232d0f94c45fd
Author: Justin TerAvest <teravest@google.com>
Date:   Wed Feb 9 14:20:03 2011 +0100

    cfq-iosched: Don't wait if queue already has requests.
    
    Commit 7667aa0630407bc07dc38dcc79d29cc0a65553c1 added logic to wait for
    the last queue of the group to become busy (have at least one request),
    so that the group does not lose out for not being continuously
    backlogged. The commit did not check for the condition that the last
    queue already has some requests. As a result, if the queue already has
    requests, wait_busy is set. Later on, cfq_select_queue() checks the
    flag, and decides that since the queue has a request now and wait_busy
    is set, the queue is expired.  This results in early expiration of the
    queue.
    
    This patch fixes the problem by adding a check to see if queue already
    has requests. If it does, wait_busy is not set. As a result, time slices
    do not expire early.
    
    The queues with more than one request are usually buffered writers.
    Testing shows improvement in isolation between buffered writers.
    
    Cc: stable@kernel.org
    Signed-off-by: Justin TerAvest <teravest@google.com>
    Reviewed-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

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

[Jens Axboe]

On 2011-03-07 12:25, Sedat Dilek wrote:
> On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2011-03-07 12:14, Sedat Dilek wrote:
>>> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>>>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>>>> $ git log -1 | cat
>>>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>>>
>>>>>     Add linux-next specific files for 20110307
>>>>>
>>>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>
>>>>> $ git pull
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>>>> for-next
>>>>> remote: Counting objects: 158, done.
>>>>> remote: Compressing objects: 100% (89/89), done.
>>>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>>>> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>>>  * branch            for-next   -> FETCH_HEAD
>>>>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>>>>> rename detection
>>>>> warning: too many files (created: 974 deleted: 462), skipping inexact
>>>>> rename detection
>>>>> Auto-merging block/blk-core.c
>>>>> Auto-merging block/blk-flush.c
>>>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>>>> Auto-merging block/cfq-iosched.c
>>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>>
>>>> Ummm... don't those conflicts come from Stephen's commits?  You would
>>>> need to revert the merge and fixup commits and then pull in the block
>>>> branch.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> tejun
>>>>
>>>
>>> I have reverted the merge-fix from Stephen "[PATCH] block: update for
>>> __blk_run_queue() API update" which changed block/blk-flush.c, this
>>> remains:
>>> ...
>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>
>>> As it is 12p.m. and sun shining, my decision and direction is clear:
>>> Lunch + City.
>>
>> Just checked here, I can pull my for-next cleanly into Linus' master.
>> What is the block tree for-next branch sha?
>>
>> --
>> Jens Axboe
>>
>>
> 
> No, I tried to merge your for-next into linux-next (which will happen
> with tomorrows linux-next).
> 
> [ linux-2.6-block.git#for-next ]
> commit b873c5d692d4d5453cceed18bb06c62bb1a73ac0
> "Merge branch 'block-for-2.6.39-core' of
> ssh:///linux/kernel/git/tj/misc into for-2.6.39/core"

linux-next should not have any CFQ changes that don't come from for-next
from the linux block tree. Are you pulling it into a linux-next that
already have some of the block changes?

-- 
Jens Axboe

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

[Sedat Dilek]

On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-03-07 12:14, Sedat Dilek wrote:
>> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>>> $ git log -1 | cat
>>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>>
>>>>     Add linux-next specific files for 20110307
>>>>
>>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>
>>>> $ git pull
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>>> for-next
>>>> remote: Counting objects: 158, done.
>>>> remote: Compressing objects: 100% (89/89), done.
>>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>>> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>>  * branch            for-next   -> FETCH_HEAD
>>>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>>>> rename detection
>>>> warning: too many files (created: 974 deleted: 462), skipping inexact
>>>> rename detection
>>>> Auto-merging block/blk-core.c
>>>> Auto-merging block/blk-flush.c
>>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>>> Auto-merging block/cfq-iosched.c
>>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>
>>> Ummm... don't those conflicts come from Stephen's commits?  You would
>>> need to revert the merge and fixup commits and then pull in the block
>>> branch.
>>>
>>> Thanks.
>>>
>>> --
>>> tejun
>>>
>>
>> I have reverted the merge-fix from Stephen "[PATCH] block: update for
>> __blk_run_queue() API update" which changed block/blk-flush.c, this
>> remains:
>> ...
>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>
>> As it is 12p.m. and sun shining, my decision and direction is clear:
>> Lunch + City.
>
> Just checked here, I can pull my for-next cleanly into Linus' master.
> What is the block tree for-next branch sha?
>
> --
> Jens Axboe
>
>

No, I tried to merge your for-next into linux-next (which will happen
with tomorrows linux-next).

[ linux-2.6-block.git#for-next ]
commit b873c5d692d4d5453cceed18bb06c62bb1a73ac0
"Merge branch 'block-for-2.6.39-core' of
ssh:///linux/kernel/git/tj/misc into for-2.6.39/core"

- Sedat -

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

[Jens Axboe]

On 2011-03-07 12:14, Sedat Dilek wrote:
> On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
>> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>>> $ git log -1 | cat
>>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>>
>>>     Add linux-next specific files for 20110307
>>>
>>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>
>>> $ git pull
>>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>>> for-next
>>> remote: Counting objects: 158, done.
>>> remote: Compressing objects: 100% (89/89), done.
>>> remote: Total 106 (delta 87), reused 21 (delta 17)
>>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>>> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>>  * branch            for-next   -> FETCH_HEAD
>>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>>> rename detection
>>> warning: too many files (created: 974 deleted: 462), skipping inexact
>>> rename detection
>>> Auto-merging block/blk-core.c
>>> Auto-merging block/blk-flush.c
>>> CONFLICT (content): Merge conflict in block/blk-flush.c
>>> Auto-merging block/cfq-iosched.c
>>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>>> Automatic merge failed; fix conflicts and then commit the result.
>>
>> Ummm... don't those conflicts come from Stephen's commits?  You would
>> need to revert the merge and fixup commits and then pull in the block
>> branch.
>>
>> Thanks.
>>
>> --
>> tejun
>>
> 
> I have reverted the merge-fix from Stephen "[PATCH] block: update for
> __blk_run_queue() API update" which changed block/blk-flush.c, this
> remains:
> ...
> CONFLICT (content): Merge conflict in block/cfq-iosched.c
> 
> As it is 12p.m. and sun shining, my decision and direction is clear:
> Lunch + City.

Just checked here, I can pull my for-next cleanly into Linus' master.
What is the block tree for-next branch sha?

-- 
Jens Axboe

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

[Sedat Dilek]

On 3/7/11, Tejun Heo <tj@kernel.org> wrote:
> On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
>> $ git log -1 | cat
>> commit c45165cd2c77843f24ca18af54044303dc2a81ab
>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date:   Mon Mar 7 17:38:41 2011 +1100
>>
>>     Add linux-next specific files for 20110307
>>
>>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>
>> $ git pull
>> git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
>> for-next
>> remote: Counting objects: 158, done.
>> remote: Compressing objects: 100% (89/89), done.
>> remote: Total 106 (delta 87), reused 21 (delta 17)
>> Receiving objects: 100% (106/106), 23.33 KiB, done.
>> Resolving deltas: 100% (87/87), completed with 34 local objects.
>> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>>  * branch            for-next   -> FETCH_HEAD
>> warning: too many files (created: 1120 deleted: 637), skipping inexact
>> rename detection
>> warning: too many files (created: 974 deleted: 462), skipping inexact
>> rename detection
>> Auto-merging block/blk-core.c
>> Auto-merging block/blk-flush.c
>> CONFLICT (content): Merge conflict in block/blk-flush.c
>> Auto-merging block/cfq-iosched.c
>> CONFLICT (content): Merge conflict in block/cfq-iosched.c
>> Automatic merge failed; fix conflicts and then commit the result.
>
> Ummm... don't those conflicts come from Stephen's commits?  You would
> need to revert the merge and fixup commits and then pull in the block
> branch.
>
> Thanks.
>
> --
> tejun
>

I have reverted the merge-fix from Stephen "[PATCH] block: update for
__blk_run_queue() API update" which changed block/blk-flush.c, this
remains:
...
CONFLICT (content): Merge conflict in block/cfq-iosched.c

As it is 12p.m. and sun shining, my decision and direction is clear:
Lunch + City.

- Sedat -

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

[Tejun Heo]

On Mon, Mar 07, 2011 at 11:41:23AM +0100, Sedat Dilek wrote:
> $ git log -1 | cat
> commit c45165cd2c77843f24ca18af54044303dc2a81ab
> Author: Stephen Rothwell <sfr@canb.auug.org.au>
> Date:   Mon Mar 7 17:38:41 2011 +1100
> 
>     Add linux-next specific files for 20110307
> 
>     Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
> for-next
> remote: Counting objects: 158, done.
> remote: Compressing objects: 100% (89/89), done.
> remote: Total 106 (delta 87), reused 21 (delta 17)
> Receiving objects: 100% (106/106), 23.33 KiB, done.
> Resolving deltas: 100% (87/87), completed with 34 local objects.
> From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
>  * branch            for-next   -> FETCH_HEAD
> warning: too many files (created: 1120 deleted: 637), skipping inexact
> rename detection
> warning: too many files (created: 974 deleted: 462), skipping inexact
> rename detection
> Auto-merging block/blk-core.c
> Auto-merging block/blk-flush.c
> CONFLICT (content): Merge conflict in block/blk-flush.c
> Auto-merging block/cfq-iosched.c
> CONFLICT (content): Merge conflict in block/cfq-iosched.c
> Automatic merge failed; fix conflicts and then commit the result.

Ummm... don't those conflicts come from Stephen's commits?  You would
need to revert the merge and fixup commits and then pull in the block
branch.

Thanks.

-- 
tejun

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

[Sedat Dilek]

Still merge conflicts with last commit [1].

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=b873c5d692d4d5453cceed18bb06c62bb1a73ac0

$ git log -1 | cat
commit c45165cd2c77843f24ca18af54044303dc2a81ab
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon Mar 7 17:38:41 2011 +1100

    Add linux-next specific files for 20110307

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
for-next
remote: Counting objects: 158, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 106 (delta 87), reused 21 (delta 17)
Receiving objects: 100% (106/106), 23.33 KiB, done.
Resolving deltas: 100% (87/87), completed with 34 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block
 * branch            for-next   -> FETCH_HEAD
warning: too many files (created: 1120 deleted: 637), skipping inexact
rename detection
warning: too many files (created: 974 deleted: 462), skipping inexact
rename detection
Auto-merging block/blk-core.c
Auto-merging block/blk-flush.c
CONFLICT (content): Merge conflict in block/blk-flush.c
Auto-merging block/cfq-iosched.c
CONFLICT (content): Merge conflict in block/cfq-iosched.c
Automatic merge failed; fix conflicts and then commit the result.



On 3/7/11, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-03-07 07:36, Tejun Heo wrote:
>> Hello, Stephen, Jens.
>>
>> On Mon, Mar 07, 2011 at 01:19:58PM +1100, Stephen Rothwell wrote:
>>> Today's linux-next merge of the block tree got a conflict in
>>> block/blk-flush.c between commit 255bb490c8c27eed484d538efe6ef6a7473bd3f6
>>> ("block: blk-flush shouldn't call directly into q->request_fn()
>>> __blk_run_queue()") from the  tree and commit
>>> ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae ("block: reimplement FLUSH/FUA
>>> to support merge") from the block tree.
>>>
>>> The latter rewrote a large part of the file, so I just used that.  If
>>> this is not correct, please fix it up in the block tree.
>>
>> I sent Jens a merge commit which should fix this yesterday.
>>
>>  http://thread.gmane.org/gmane.linux.kernel/1101766/focus=1108915
>>
>> So, the merge problem should go away soonish.
>
> Merged now, so this conflict should be gone from linux-next as of now.
>
> --
> Jens Axboe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Jens Axboe]

On 2011-03-07 07:36, Tejun Heo wrote:
> Hello, Stephen, Jens.
> 
> On Mon, Mar 07, 2011 at 01:19:58PM +1100, Stephen Rothwell wrote:
>> Today's linux-next merge of the block tree got a conflict in
>> block/blk-flush.c between commit 255bb490c8c27eed484d538efe6ef6a7473bd3f6
>> ("block: blk-flush shouldn't call directly into q->request_fn()
>> __blk_run_queue()") from the  tree and commit
>> ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae ("block: reimplement FLUSH/FUA
>> to support merge") from the block tree.
>>
>> The latter rewrote a large part of the file, so I just used that.  If
>> this is not correct, please fix it up in the block tree.
> 
> I sent Jens a merge commit which should fix this yesterday.
> 
>  http://thread.gmane.org/gmane.linux.kernel/1101766/focus=1108915
> 
> So, the merge problem should go away soonish.

Merged now, so this conflict should be gone from linux-next as of now.

-- 
Jens Axboe

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

[Tejun Heo]

Hello, Stephen, Jens.

On Mon, Mar 07, 2011 at 01:19:58PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the block tree got a conflict in
> block/blk-flush.c between commit 255bb490c8c27eed484d538efe6ef6a7473bd3f6
> ("block: blk-flush shouldn't call directly into q->request_fn()
> __blk_run_queue()") from the  tree and commit
> ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae ("block: reimplement FLUSH/FUA
> to support merge") from the block tree.
> 
> The latter rewrote a large part of the file, so I just used that.  If
> this is not correct, please fix it up in the block tree.

I sent Jens a merge commit which should fix this yesterday.

 http://thread.gmane.org/gmane.linux.kernel/1101766/focus=1108915

So, the merge problem should go away soonish.

Thank you.

-- 
tejun

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
block/blk-flush.c between commit 255bb490c8c27eed484d538efe6ef6a7473bd3f6
("block: blk-flush shouldn't call directly into q->request_fn()
__blk_run_queue()") from the  tree and commit
ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae ("block: reimplement FLUSH/FUA
to support merge") from the block tree.

The latter rewrote a large part of the file, so I just used that.  If
this is not correct, please fix it up in the block tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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-core.c between commit 5e00d1b5b4c10fb839afd5ce61db8e24339454b0
("BLOCK: fix bio.bi_rw handling") from Linus' tree (v2.6.36-rc4) and
commit 28e7d1845216538303bb95d679d8fd4de50e2f1a ("block: drop barrier
ordering by queue draining") from the block tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc block/blk-core.c
index 32a1c12,4df8e84..0000000
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@@ -1198,13 -1182,15 +1182,15 @@@ static int __make_request(struct reques
  	int el_ret;
  	unsigned int bytes = bio->bi_size;
  	const unsigned short prio = bio_prio(bio);
 -	const bool sync = (bio->bi_rw & REQ_SYNC);
 -	const bool unplug = (bio->bi_rw & REQ_UNPLUG);
 -	const unsigned int ff = bio->bi_rw & REQ_FAILFAST_MASK;
 +	const bool sync = !!(bio->bi_rw & REQ_SYNC);
 +	const bool unplug = !!(bio->bi_rw & REQ_UNPLUG);
 +	const unsigned long ff = bio->bi_rw & REQ_FAILFAST_MASK;
+ 	int where = ELEVATOR_INSERT_SORT;
  	int rw_flags;
  
- 	if ((bio->bi_rw & REQ_HARDBARRIER) &&
- 	    (q->next_ordered == QUEUE_ORDERED_NONE)) {
+ 	/* REQ_HARDBARRIER is no more */
+ 	if (WARN_ONCE(bio->bi_rw & REQ_HARDBARRIER,
+ 		"block: HARDBARRIER is deprecated, use FLUSH/FUA instead\n")) {
  		bio_endio(bio, -EOPNOTSUPP);
  		return 0;
  	}

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

[Jens Axboe]

On Thu, Apr 29 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> fs/block_dev.c between commit b8af67e2681c693a21f3933e3bdfce4cf66596d3
> ("fs/block_dev.c: fix performance regression in O_DIRECT|O_SYNC writes to
> block devices") from Linus' tree and commit
> fbd9b09a177a481eda256447c881f014f29034fe ("blkdev: generalize flags for
> blkdev_issue_fn functions") from the block tree.
> 
> I fixed it up (see below) and can carry the fix for a while.

I'll merge -linus in to resolve this one so you don't have to carry this
fix.

-- 
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
fs/block_dev.c between commit b8af67e2681c693a21f3933e3bdfce4cf66596d3
("fs/block_dev.c: fix performance regression in O_DIRECT|O_SYNC writes to
block devices") from Linus' tree and commit
fbd9b09a177a481eda256447c881f014f29034fe ("blkdev: generalize flags for
blkdev_issue_fn functions") from the block tree.

I fixed it up (see below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/block_dev.c
index 6dcee88,dd76930..0000000
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@@ -406,23 -406,17 +406,24 @@@ static loff_t block_llseek(struct file 
   
  int blkdev_fsync(struct file *filp, struct dentry *dentry, int datasync)
  {
 -	struct block_device *bdev = I_BDEV(filp->f_mapping->host);
 +	struct inode *bd_inode = filp->f_mapping->host;
 +	struct block_device *bdev = I_BDEV(bd_inode);
  	int error;
  
 -	error = sync_blockdev(bdev);
 -	if (error)
 -		return error;
 -	
 +	/*
 +	 * There is no need to serialise calls to blkdev_issue_flush with
 +	 * i_mutex and doing so causes performance issues with concurrent
 +	 * O_SYNC writers to a block device.
 +	 */
 +	mutex_unlock(&bd_inode->i_mutex);
 +
- 	error = blkdev_issue_flush(bdev, NULL);
+ 	error = blkdev_issue_flush(bdev, GFP_KERNEL, NULL,
+ 				(BLKDEV_IFL_WAIT));
  	if (error == -EOPNOTSUPP)
  		error = 0;
 +
 +	mutex_lock(&bd_inode->i_mutex);
 +
  	return error;
  }
  EXPORT_SYMBOL(blkdev_fsync);

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

[Li Zefan]

Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> block/Kconfig between commit 67523c48aa74d5637848edeccf285af1c60bf14a
> ("cgroups: blkio subsystem as module") from Linus' tree and commit
> 910ac735bad53ce54741a72a5b19ab69794ae069 ("block: make CONFIG_BLK_CGROUP
> visible") from the block tree.
> 
> I used the block tree version.

The merge is correct, thanks!

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
block/Kconfig between commit 67523c48aa74d5637848edeccf285af1c60bf14a
("cgroups: blkio subsystem as module") from Linus' tree and commit
910ac735bad53ce54741a72a5b19ab69794ae069 ("block: make CONFIG_BLK_CGROUP
visible") from the block tree.

I used the block tree version.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

Hi Jens,

On Thu, 25 Feb 2010 08:47:57 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> I was, unfortunately I forgot to resolve the conflict yesterday. Your
> fix confuses me a bit - I was expecting the first hunk, but what is the
> second hunk doing? Conceptually good though, perhaps there are more
> conflicts than I was expecting :-)

The second hunk was not part of the conflict, but "git diff" gives us more
than just the conflicted bit of the file.

> I'll update here as well so it disappears next time you pull.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Jens Axboe]

On Thu, Feb 25 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> include/linux/blkdev.h between commit
> 79da0644a8e0838522828f106e4049639eea6baf ("Revert "block: improve
> queue_should_plug() by looking at IO depths"") from Linus' tree and
> commit 488991e28e55b4fbca8067edf0259f69d1a6f92c ("block: Added in
> stricter no merge semantics for block I/O") from the block tree.
> 
> Context changes - I have fixed it up (see below) and can carry the fix
> for a while.  I suspect that you were expecting this. :-)

I was, unfortunately I forgot to resolve the conflict yesterday. Your
fix confuses me a bit - I was expecting the first hunk, but what is the
second hunk doing? Conceptually good though, perhaps there are more
conflicts than I was expecting :-)

I'll update here as well so it disappears next time you pull.

-- 
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
include/linux/blkdev.h between commit
79da0644a8e0838522828f106e4049639eea6baf ("Revert "block: improve
queue_should_plug() by looking at IO depths"") from Linus' tree and
commit 488991e28e55b4fbca8067edf0259f69d1a6f92c ("block: Added in
stricter no merge semantics for block I/O") from the block tree.

Context changes - I have fixed it up (see below) and can carry the fix
for a while.  I suspect that you were expecting this. :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/blkdev.h
index 1896e86,f71f5c5..0000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -461,7 -461,9 +461,8 @@@ struct request_queu
  #define QUEUE_FLAG_NONROT      14	/* non-rotational device (SSD) */
  #define QUEUE_FLAG_VIRT        QUEUE_FLAG_NONROT /* paravirt device */
  #define QUEUE_FLAG_IO_STAT     15	/* do IO stats */
 -#define QUEUE_FLAG_CQ	       16	/* hardware does queuing */
 -#define QUEUE_FLAG_DISCARD     17	/* supports DISCARD */
 -#define QUEUE_FLAG_NOXMERGES   18	/* No extended merges */
 +#define QUEUE_FLAG_DISCARD     16	/* supports DISCARD */
++#define QUEUE_FLAG_NOXMERGES   17	/* No extended merges */
  
  #define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
  				 (1 << QUEUE_FLAG_CLUSTER) |		\
@@@ -585,8 -587,11 +586,10 @@@ enum 
  
  #define blk_queue_plugged(q)	test_bit(QUEUE_FLAG_PLUGGED, &(q)->queue_flags)
  #define blk_queue_tagged(q)	test_bit(QUEUE_FLAG_QUEUED, &(q)->queue_flags)
 -#define blk_queue_queuing(q)	test_bit(QUEUE_FLAG_CQ, &(q)->queue_flags)
  #define blk_queue_stopped(q)	test_bit(QUEUE_FLAG_STOPPED, &(q)->queue_flags)
  #define blk_queue_nomerges(q)	test_bit(QUEUE_FLAG_NOMERGES, &(q)->queue_flags)
+ #define blk_queue_noxmerges(q)	\
+ 	test_bit(QUEUE_FLAG_NOXMERGES, &(q)->queue_flags)
  #define blk_queue_nonrot(q)	test_bit(QUEUE_FLAG_NONROT, &(q)->queue_flags)
  #define blk_queue_io_stat(q)	test_bit(QUEUE_FLAG_IO_STAT, &(q)->queue_flags)
  #define blk_queue_flushing(q)	((q)->ordseq)

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

[Jens Axboe]

On Thu, Jun 25 2009, Jens Axboe wrote:
> On Thu, Jun 25 2009, Stephen Rothwell wrote:
> > On Thu, 25 Jun 2009 13:15:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > I can't see how to easily fix this up, so I have dropped the block tree
> > > for today (since it only contained 2.6.32 material, right?).
> > 
> > I also dropped the device-mapper tree for today as it was based on the
> > block tree (and dragged in what I had just dropped) and, in any case, all
> > its patches have been merged upstream.
> 
> OK to both, I'm fixing up the writeback conflicts right now.

Should be good to go again.

-- 
Jens Axboe

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

[Jens Axboe]

On Thu, Jun 25 2009, Stephen Rothwell wrote:
> On Thu, 25 Jun 2009 13:15:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I can't see how to easily fix this up, so I have dropped the block tree
> > for today (since it only contained 2.6.32 material, right?).
> 
> I also dropped the device-mapper tree for today as it was based on the
> block tree (and dragged in what I had just dropped) and, in any case, all
> its patches have been merged upstream.

OK to both, I'm fixing up the writeback conflicts right now.

-- 
Jens Axboe

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Thu, 25 Jun 2009 13:15:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I can't see how to easily fix this up, so I have dropped the block tree
> for today (since it only contained 2.6.32 material, right?).

I also dropped the device-mapper tree for today as it was based on the
block tree (and dragged in what I had just dropped) and, in any case, all
its patches have been merged upstream.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/fs-writeback.c between commit 01c031945f2755c7afaaf456088543312f2b72ea
("cleanup __writeback_single_inode") from Linus' tree and commit
385b54f15a82a85a505e0f5e8579605f5742c648 ("writeback: move dirty inodes
from super_block to backing_dev_info") from the block tree (and probably
others).

I can't see how to easily fix this up, so I have dropped the block tree
for today (since it only contained 2.6.32 material, right?).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]