linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2017-04-26  5:47 Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2017-04-26  5:47 UTC (permalink / raw)
  To: Martin K. Petersen, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Damien Le Moal, Christoph Hellwig

Hi all,

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

  drivers/scsi/sd.c

between commit:

  81d926e8b552 ("sd: split sd_setup_discard_cmnd")

from the block tree and commit:

  7529fbb0080d ("scsi: sd: Fix function descriptions")

from the scsi-mkp tree.

I fixed it up (I just used the former version) 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2024-04-18  4:55 Stephen Rothwell
@ 2024-04-18  5:57 ` Christoph Hellwig
  0 siblings, 0 replies; 13+ messages in thread
From: Christoph Hellwig @ 2024-04-18  5:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Martin K. Petersen, Jens Axboe, Christoph Hellwig,
	Damien Le Moal, Linux Kernel Mailing List,
	Linux Next Mailing List

Thanks Stephen,

the conflict resolution looks good to me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2024-04-18  4:55 Stephen Rothwell
  2024-04-18  5:57 ` Christoph Hellwig
  0 siblings, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2024-04-18  4:55 UTC (permalink / raw)
  To: Martin K. Petersen, Jens Axboe
  Cc: Christoph Hellwig, Damien Le Moal, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the scsi-mkp tree got conflicts in:

  block/blk-settings.c
  include/linux/blkdev.h

between commit:

  e4eb37cc0f3e ("block: Remove elevator required features")

from the block tree and commit:

  ec84ca4025c0 ("scsi: block: Remove now unused queue limits helpers")

from the scsi-mkp 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-settings.c
index 8e1d7ed52fef,292aadf8d807..000000000000
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@@ -1048,28 -822,22 +825,6 @@@ void blk_queue_write_cache(struct reque
  }
  EXPORT_SYMBOL_GPL(blk_queue_write_cache);
  
--/**
-  * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
-  * @q:		the request queue for the device
-  * @dev:	the device pointer for dma
 - * blk_queue_required_elevator_features - Set a queue required elevator features
 - * @q:		the request queue for the target device
 - * @features:	Required elevator features OR'ed together
-- *
-  * Tell the block layer about merging the segments by dma map of @q.
 - * Tell the block layer that for the device controlled through @q, only the
 - * only elevators that can be used are those that implement at least the set of
 - * features specified by @features.
-- */
- bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
- 				       struct device *dev)
 -void blk_queue_required_elevator_features(struct request_queue *q,
 -					  unsigned int features)
--{
- 	unsigned long boundary = dma_get_merge_boundary(dev);
- 
- 	if (!boundary)
- 		return false;
- 
- 	/* No need to update max_segment_size. see blk_queue_virt_boundary() */
- 	blk_queue_virt_boundary(q, boundary);
- 
- 	return true;
 -	q->required_elevator_features = features;
--}
- EXPORT_SYMBOL_GPL(blk_queue_can_use_dma_map_merging);
 -EXPORT_SYMBOL_GPL(blk_queue_required_elevator_features);
--
  /**
   * disk_set_zoned - inidicate a zoned device
   * @disk:	gendisk to configure
diff --cc include/linux/blkdev.h
index 2c535af79529,e3c7082efa39..000000000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -924,9 -942,15 +926,6 @@@ disk_alloc_independent_access_ranges(st
  void disk_set_independent_access_ranges(struct gendisk *disk,
  				struct blk_independent_access_ranges *iars);
  
- extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
- 					      struct device *dev);
 -/*
 - * Elevator features for blk_queue_required_elevator_features:
 - */
 -/* Supports zoned block devices sequential write constraint */
 -#define ELEVATOR_F_ZBD_SEQ_WRITE	(1U << 0)
 -
 -extern void blk_queue_required_elevator_features(struct request_queue *q,
 -						 unsigned int features);
--
  bool __must_check blk_get_queue(struct request_queue *);
  extern void blk_put_queue(struct request_queue *);
  

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2022-02-21 21:59 broonie
  2022-02-22  5:57 ` Jinpu Wang
@ 2022-03-01  7:31 ` Stephen Rothwell
  1 sibling, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2022-03-01  7:31 UTC (permalink / raw)
  To: Jens Axboe
  Cc: broonie, Martin K . Petersen, Christoph Hellwig, Gioh Kim,
	Jack Wang, Linux Kernel Mailing List, Linux Next Mailing List,
	Md Haris Iqbal, James Bottomley

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

Hi all,

On Mon, 21 Feb 2022 21:59:11 +0000 broonie@kernel.org wrote:
> 
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
> 
>   drivers/block/rnbd/rnbd-clt.c
> 
> between commit:
> 
>   448025c103938 ("block/rnbd: client device does not care queue/rotational")
> 
> from the block tree and commit:
> 
>   e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")
> 
> from the scsi-mkp 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.
> 
> diff --cc drivers/block/rnbd/rnbd-clt.c
> index 1f63f308eb394,dc192d2738854..0000000000000
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
>   	}
>   
>   	rnbd_clt_info(dev,
> - 		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
>  -		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
> ++		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
>   		       dev->gd->disk_name, dev->nsectors,
>   		       dev->logical_block_size, dev->physical_block_size,
> - 		       dev->max_write_same_sectors, dev->max_discard_sectors,
> + 		       dev->max_discard_sectors,
>   		       dev->discard_granularity, dev->discard_alignment,
>   		       dev->secure_discard, dev->max_segments,
>  -		       dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
>  +		       dev->max_hw_sectors, dev->wc, dev->fua);
>   
>   	mutex_unlock(&dev->lock);
>   	rnbd_clt_put_sess(sess);

This is now a conflict between the scsi tree and the block tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2022-02-21 22:06 broonie
@ 2022-03-01  7:29 ` Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2022-03-01  7:29 UTC (permalink / raw)
  To: Jens Axboe, James Bottomley
  Cc: broonie, Martin K . Petersen, Chaitanya Kulkarni,
	Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

On Mon, 21 Feb 2022 22:06:22 +0000 broonie@kernel.org wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
> 
>   block/blk-lib.c
> 
> between commit:
> 
>   0a3140ea0fae3 ("block: pass a block_device and opf to blk_next_bio")
> 
> from the block tree and commit:
> 
>   2988062985d59 ("scsi: block: Remove REQ_OP_WRITE_SAME support")
> 
> from the scsi-mkp 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.
> 
> diff --cc block/blk-lib.c
> index fc6ea52e74824,bf5254ccdb5f8..0000000000000
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> 
> (took the deletion of _WRITE_SAME from scsi-mkp)

This is now a conflict between the scsi tree and the block tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2022-02-21 21:59 broonie
@ 2022-02-22  5:57 ` Jinpu Wang
  2022-03-01  7:31 ` Stephen Rothwell
  1 sibling, 0 replies; 13+ messages in thread
From: Jinpu Wang @ 2022-02-22  5:57 UTC (permalink / raw)
  To: broonie
  Cc: Martin K . Petersen, Christoph Hellwig, Gioh Kim, Jens Axboe,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Md Haris Iqbal

On Mon, Feb 21, 2022 at 10:59 PM <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
>   drivers/block/rnbd/rnbd-clt.c
>
> between commit:
>
>   448025c103938 ("block/rnbd: client device does not care queue/rotational")
>
> from the block tree and commit:
>
>   e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")
>
> from the scsi-mkp 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.
Hi Broonie,

Thanks for fixing it up, it looks good. We will pay attention on this next time!

Regards!
Jinpu Wang
>
> diff --cc drivers/block/rnbd/rnbd-clt.c
> index 1f63f308eb394,dc192d2738854..0000000000000
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
>         }
>
>         rnbd_clt_info(dev,
> -                      "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
>  -                     "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
> ++                     "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
>                        dev->gd->disk_name, dev->nsectors,
>                        dev->logical_block_size, dev->physical_block_size,
> -                      dev->max_write_same_sectors, dev->max_discard_sectors,
> +                      dev->max_discard_sectors,
>                        dev->discard_granularity, dev->discard_alignment,
>                        dev->secure_discard, dev->max_segments,
>  -                     dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
>  +                     dev->max_hw_sectors, dev->wc, dev->fua);
>
>         mutex_unlock(&dev->lock);
>         rnbd_clt_put_sess(sess);

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2022-02-21 22:06 broonie
  2022-03-01  7:29 ` Stephen Rothwell
  0 siblings, 1 reply; 13+ messages in thread
From: broonie @ 2022-02-21 22:06 UTC (permalink / raw)
  To: Martin K . Petersen
  Cc: Chaitanya Kulkarni, Christoph Hellwig, Jens Axboe,
	Linux Kernel Mailing List, Linux Next Mailing List

Hi all,

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

  block/blk-lib.c

between commit:

  0a3140ea0fae3 ("block: pass a block_device and opf to blk_next_bio")

from the block tree and commit:

  2988062985d59 ("scsi: block: Remove REQ_OP_WRITE_SAME support")

from the scsi-mkp 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.

diff --cc block/blk-lib.c
index fc6ea52e74824,bf5254ccdb5f8..0000000000000
--- a/block/blk-lib.c
+++ b/block/blk-lib.c

(took the deletion of _WRITE_SAME from scsi-mkp)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2022-02-21 21:59 broonie
  2022-02-22  5:57 ` Jinpu Wang
  2022-03-01  7:31 ` Stephen Rothwell
  0 siblings, 2 replies; 13+ messages in thread
From: broonie @ 2022-02-21 21:59 UTC (permalink / raw)
  To: Martin K . Petersen
  Cc: Christoph Hellwig, Gioh Kim, Jack Wang, Jens Axboe,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Md Haris Iqbal

Hi all,

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

  drivers/block/rnbd/rnbd-clt.c

between commit:

  448025c103938 ("block/rnbd: client device does not care queue/rotational")

from the block tree and commit:

  e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")

from the scsi-mkp 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.

diff --cc drivers/block/rnbd/rnbd-clt.c
index 1f63f308eb394,dc192d2738854..0000000000000
--- a/drivers/block/rnbd/rnbd-clt.c
+++ b/drivers/block/rnbd/rnbd-clt.c
@@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
  	}
  
  	rnbd_clt_info(dev,
- 		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
 -		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
++		       "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
  		       dev->gd->disk_name, dev->nsectors,
  		       dev->logical_block_size, dev->physical_block_size,
- 		       dev->max_write_same_sectors, dev->max_discard_sectors,
+ 		       dev->max_discard_sectors,
  		       dev->discard_granularity, dev->discard_alignment,
  		       dev->secure_discard, dev->max_segments,
 -		       dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
 +		       dev->max_hw_sectors, dev->wc, dev->fua);
  
  	mutex_unlock(&dev->lock);
  	rnbd_clt_put_sess(sess);

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2021-01-27  6:58 Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2021-01-27  6:58 UTC (permalink / raw)
  To: Martin K. Petersen, Jens Axboe
  Cc: Douglas Gilbert, Guoqing Jiang, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

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

  drivers/scsi/sg.c

between commit:

  8eeed0b554b9 ("block: remove unnecessary argument from blk_execute_rq_nowait")

from the block tree and vaious commits from the scsi-mkp 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/scsi/sg.c
index 4383d93110f8,c5a34bb91335..000000000000
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@@ -437,73 -858,243 +858,242 @@@ sg_rq_state_chg(struct sg_request *srp
  	return 0;
  }
  
- static ssize_t
- sg_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos)
+ /*
+  * All writes and submits converge on this function to launch the SCSI
+  * command/request (via blk_execute_rq_nowait). Returns a pointer to a
+  * sg_request object holding the request just issued or a negated errno
+  * value twisted by ERR_PTR.
+  */
+ static struct sg_request *
+ sg_common_write(struct sg_fd *sfp, struct sg_comm_wr_t *cwrp)
  {
- 	Sg_device *sdp;
- 	Sg_fd *sfp;
- 	Sg_request *srp;
- 	int req_pack_id = -1;
- 	sg_io_hdr_t *hp;
- 	struct sg_header *old_hdr;
- 	int retval;
+ 	bool at_head;
+ 	int res = 0;
+ 	int dxfr_len, dir, cmd_len;
+ 	int pack_id = SG_PACK_ID_WILDCARD;
+ 	u32 rq_flags;
+ 	struct sg_device *sdp = sfp->parentdp;
+ 	struct sg_request *srp;
+ 	struct sg_io_hdr *hi_p;
+ 
+ 	hi_p = cwrp->h3p;
+ 	dir = hi_p->dxfer_direction;
+ 	dxfr_len = hi_p->dxfer_len;
+ 	rq_flags = hi_p->flags;
+ 	pack_id = hi_p->pack_id;
+ 	if (dxfr_len >= SZ_256M)
+ 		return ERR_PTR(-EINVAL);
+ 
+ 	srp = sg_setup_req(sfp, dxfr_len, cwrp);
+ 	if (IS_ERR(srp))
+ 		return srp;
+ 	srp->rq_flags = rq_flags;
+ 	srp->pack_id = pack_id;
+ 
+ 	cmd_len = hi_p->cmd_len;
+ 	memcpy(&srp->s_hdr3, hi_p, sizeof(srp->s_hdr3));
+ 	srp->cmd_opcode = cwrp->cmnd[0];/* hold opcode of command for debug */
+ 	SG_LOG(4, sfp, "%s: opcode=0x%02x, cdb_sz=%d, pack_id=%d\n", __func__,
+ 	       (int)cwrp->cmnd[0], cmd_len, pack_id);
+ 
+ 	res = sg_start_req(srp, cwrp->cmnd, cmd_len, dir);
+ 	if (res < 0)		/* probably out of space --> -ENOMEM */
+ 		goto err_out;
+ 	if (unlikely(SG_IS_DETACHING(sdp))) {
+ 		res = -ENODEV;
+ 		goto err_out;
+ 	}
+ 	if (unlikely(test_bit(SG_FRQ_BLK_PUT_REQ, srp->frq_bm) || !srp->rq)) {
+ 		res = -EIDRM;	/* this failure unexpected but observed */
+ 		goto err_out;
+ 	}
+ 	if (xa_get_mark(&sfp->srp_arr, srp->rq_idx, SG_XA_RQ_FREE)) {
+ 		SG_LOG(1, sfp, "%s: ahhh, request erased!!!\n", __func__);
+ 		res = -ENODEV;
+ 		goto err_out;
+ 	}
+ 	srp->rq->timeout = cwrp->timeout;
+ 	kref_get(&sfp->f_ref); /* sg_rq_end_io() does kref_put(). */
+ 	res = sg_rq_state_chg(srp, SG_RS_BUSY, SG_RS_INFLIGHT, false,
+ 			      __func__);
+ 	if (res)
+ 		goto err_out;
+ 	srp->start_ns = ktime_get_boottime_ns();
+ 	srp->duration = 0;
+ 
+ 	if (srp->s_hdr3.interface_id == '\0')
+ 		at_head = true; /* backward compatibility: v1+v2 interfaces */
+ 	else if (test_bit(SG_FFD_Q_AT_TAIL, sfp->ffd_bm))
+ 	/* cmd flags can override sfd setting */
+ 		at_head = !!(srp->rq_flags & SG_FLAG_Q_AT_HEAD);
+ 	else            /* this sfd is defaulting to head */
+ 		at_head = !(srp->rq_flags & SG_FLAG_Q_AT_TAIL);
+ 	if (!test_bit(SG_FRQ_SYNC_INVOC, srp->frq_bm))
+ 		atomic_inc(&sfp->submitted);
 -	blk_execute_rq_nowait(sdp->device->request_queue, sdp->disk,
 -			      srp->rq, at_head, sg_rq_end_io);
++	blk_execute_rq_nowait(sdp->disk, srp->rq, at_head, sg_rq_end_io);
+ 	return srp;
+ err_out:
+ 	sg_finish_scsi_blk_rq(srp);
+ 	sg_deact_request(sfp, srp);
+ 	return ERR_PTR(res);
+ }
  
- 	/*
- 	 * This could cause a response to be stranded. Close the associated
- 	 * file descriptor to free up any resources being held.
- 	 */
- 	retval = sg_check_file_access(filp, __func__);
- 	if (retval)
- 		return retval;
+ /*
+  * This function is called by wait_event_interruptible in sg_read() and
+  * sg_ctl_ioreceive(). wait_event_interruptible will return if this one
+  * returns true (or an event like a signal (e.g. control-C) occurs).
+  */
  
- 	if ((!(sfp = (Sg_fd *) filp->private_data)) || (!(sdp = sfp->parentdp)))
- 		return -ENXIO;
- 	SCSI_LOG_TIMEOUT(3, sg_printk(KERN_INFO, sdp,
- 				      "sg_read: count=%d\n", (int) count));
+ static inline bool
+ sg_get_ready_srp(struct sg_fd *sfp, struct sg_request **srpp, int pack_id)
+ {
+ 	struct sg_request *srp;
  
- 	if (sfp->force_packid)
- 		retval = get_sg_io_pack_id(&req_pack_id, buf, count);
- 	if (retval)
- 		return retval;
+ 	if (unlikely(SG_IS_DETACHING(sfp->parentdp))) {
+ 		*srpp = NULL;
+ 		return true;
+ 	}
+ 	srp = sg_find_srp_by_id(sfp, pack_id);
+ 	*srpp = srp;
+ 	return !!srp;
+ }
  
- 	srp = sg_get_rq_mark(sfp, req_pack_id);
- 	if (!srp) {		/* now wait on packet to arrive */
- 		if (atomic_read(&sdp->detaching))
- 			return -ENODEV;
- 		if (filp->f_flags & O_NONBLOCK)
- 			return -EAGAIN;
- 		retval = wait_event_interruptible(sfp->read_wait,
- 			(atomic_read(&sdp->detaching) ||
- 			(srp = sg_get_rq_mark(sfp, req_pack_id))));
- 		if (atomic_read(&sdp->detaching))
- 			return -ENODEV;
- 		if (retval)
- 			/* -ERESTARTSYS as signal hit process */
- 			return retval;
+ /*
+  * Returns number of bytes copied to user space provided sense buffer or
+  * negated errno value.
+  */
+ static int
+ sg_copy_sense(struct sg_request *srp)
+ {
+ 	int sb_len_ret = 0;
+ 	int scsi_stat;
+ 
+ 	/* If need be, copy the sense buffer to the user space */
+ 	scsi_stat = srp->rq_result & 0xff;
+ 	if ((scsi_stat & SAM_STAT_CHECK_CONDITION) ||
+ 	    (driver_byte(srp->rq_result) & DRIVER_SENSE)) {
+ 		int sb_len = min_t(int, SCSI_SENSE_BUFFERSIZE, srp->sense_len);
+ 		int mx_sb_len = srp->s_hdr3.mx_sb_len;
+ 		u8 *sbp = srp->sense_bp;
+ 		void __user *up = srp->s_hdr3.sbp;
+ 
+ 		srp->sense_bp = NULL;
+ 		if (up && mx_sb_len > 0 && sbp) {
+ 			sb_len = min_t(int, mx_sb_len, sb_len);
+ 			/* Additional sense length field */
+ 			sb_len_ret = 8 + (int)sbp[7];
+ 			sb_len_ret = min_t(int, sb_len_ret, sb_len);
+ 			if (copy_to_user(up, sbp, sb_len_ret))
+ 				sb_len_ret = -EFAULT;
+ 		} else {
+ 			sb_len_ret = 0;
+ 		}
+ 		mempool_free(sbp, sg_sense_pool);
  	}
- 	if (srp->header.interface_id != '\0')
- 		return sg_new_read(sfp, buf, count, srp);
+ 	return sb_len_ret;
+ }
  
- 	hp = &srp->header;
- 	old_hdr = kzalloc(SZ_SG_HEADER, GFP_KERNEL);
- 	if (!old_hdr)
- 		return -ENOMEM;
+ static int
+ sg_rec_state_v3(struct sg_fd *sfp, struct sg_request *srp)
+ {
+ 	int sb_len_wr;
+ 	u32 rq_res = srp->rq_result;
+ 
+ 	sb_len_wr = sg_copy_sense(srp);
+ 	if (sb_len_wr < 0)
+ 		return sb_len_wr;
+ 	if (rq_res & SG_ML_RESULT_MSK)
+ 		srp->rq_info |= SG_INFO_CHECK;
+ 	if (unlikely(SG_IS_DETACHING(sfp->parentdp)))
+ 		srp->rq_info |= SG_INFO_DEVICE_DETACHING;
+ 	return 0;
+ }
+ 
+ static ssize_t
+ sg_receive_v3(struct sg_fd *sfp, struct sg_request *srp, size_t count,
+ 	      void __user *p)
+ {
+ 	int err, err2;
+ 	int rq_result = srp->rq_result;
+ 	struct sg_io_hdr hdr3;
+ 	struct sg_io_hdr *hp = &hdr3;
  
- 	old_hdr->reply_len = (int) hp->timeout;
- 	old_hdr->pack_len = old_hdr->reply_len; /* old, strange behaviour */
- 	old_hdr->pack_id = hp->pack_id;
- 	old_hdr->twelve_byte =
- 	    ((srp->data.cmd_opcode >= 0xc0) && (12 == hp->cmd_len)) ? 1 : 0;
- 	old_hdr->target_status = hp->masked_status;
- 	old_hdr->host_status = hp->host_status;
- 	old_hdr->driver_status = hp->driver_status;
- 	if ((CHECK_CONDITION & hp->masked_status) ||
- 	    (DRIVER_SENSE & hp->driver_status))
- 		memcpy(old_hdr->sense_buffer, srp->sense_b,
- 		       sizeof (old_hdr->sense_buffer));
- 	switch (hp->host_status) {
- 	/* This setup of 'result' is for backward compatibility and is best
- 	   ignored by the user who should use target, host + driver status */
+ 	if (in_compat_syscall()) {
+ 		if (count < sizeof(struct compat_sg_io_hdr)) {
+ 			err = -EINVAL;
+ 			goto err_out;
+ 		}
+ 	} else if (count < SZ_SG_IO_HDR) {
+ 		err = -EINVAL;
+ 		goto err_out;
+ 	}
+ 	SG_LOG(3, sfp, "%s: srp=0x%pK\n", __func__, srp);
+ 	err = sg_rec_state_v3(sfp, srp);
+ 	memset(hp, 0, sizeof(*hp));
+ 	memcpy(hp, &srp->s_hdr3, sizeof(srp->s_hdr3));
+ 	hp->sb_len_wr = srp->sense_len;
+ 	hp->info = srp->rq_info;
+ 	hp->resid = srp->in_resid;
+ 	hp->duration = srp->duration;
+ 	hp->status = rq_result & 0xff;
+ 	hp->masked_status = status_byte(rq_result);
+ 	hp->msg_status = msg_byte(rq_result);
+ 	hp->host_status = host_byte(rq_result);
+ 	hp->driver_status = driver_byte(rq_result);
+ 	err2 = put_sg_io_hdr(hp, p);
+ 	err = err ? err : err2;
+ 	err2 = sg_rq_state_chg(srp, atomic_read(&srp->rq_st), SG_RS_RCV_DONE,
+ 			       false, __func__);
+ 	if (err2)
+ 		err = err ? err : err2;
+ err_out:
+ 	sg_finish_scsi_blk_rq(srp);
+ 	sg_deact_request(sfp, srp);
+ 	return err;
+ }
+ 
+ /*
+  * Completes a v3 request/command. Called from sg_read {v2 or v3},
+  * ioctl(SG_IO) {for v3}, or from ioctl(SG_IORECEIVE) when its
+  * completing a v3 request/command.
+  */
+ static int
+ sg_read_v1v2(void __user *buf, int count, struct sg_fd *sfp,
+ 	     struct sg_request *srp)
+ {
+ 	int res = 0;
+ 	u32 rq_result = srp->rq_result;
+ 	struct sg_header *h2p;
+ 	struct sg_slice_hdr3 *sh3p;
+ 	struct sg_header a_v2hdr;
+ 
+ 	h2p = &a_v2hdr;
+ 	memset(h2p, 0, SZ_SG_HEADER);
+ 	sh3p = &srp->s_hdr3;
+ 	h2p->reply_len = (int)sh3p->timeout;
+ 	h2p->pack_len = h2p->reply_len; /* old, strange behaviour */
+ 	h2p->pack_id = sh3p->pack_id;
+ 	h2p->twelve_byte = (srp->cmd_opcode >= 0xc0 && sh3p->cmd_len == 12);
+ 	h2p->target_status = status_byte(rq_result);
+ 	h2p->host_status = host_byte(rq_result);
+ 	h2p->driver_status = driver_byte(rq_result);
+ 	if ((CHECK_CONDITION & status_byte(rq_result)) ||
+ 	    (DRIVER_SENSE & driver_byte(rq_result))) {
+ 		if (srp->sense_bp) {
+ 			u8 *sbp = srp->sense_bp;
+ 
+ 			srp->sense_bp = NULL;
+ 			memcpy(h2p->sense_buffer, sbp,
+ 			       sizeof(h2p->sense_buffer));
+ 			mempool_free(sbp, sg_sense_pool);
+ 		}
+ 	}
+ 	switch (host_byte(rq_result)) {
+ 	/*
+ 	 * This following setting of 'result' is for backward compatibility
+ 	 * and is best ignored by the user who should use target, host and
+ 	 * driver status.
+ 	 */
  	case DID_OK:
  	case DID_PASSTHROUGH:
  	case DID_SOFT_ERROR:

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2019-02-11  4:23 Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2019-02-11  4:23 UTC (permalink / raw)
  To: Martin K. Petersen, Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, James Bottomley

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

Hi all,

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

  include/linux/blkdev.h

between commit:

  eca7abf31abb ("block: queue flag cleanup")

from the block tree and commit:

  8b3238cabd50 ("scsi: block: remove bidi support")

from the scsi-mkp 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/blkdev.h
index 3603270cb82d,21beb456b97a..000000000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -572,33 -567,37 +567,32 @@@ struct request_queue 
  	u64			write_hints[BLK_MAX_WRITE_HINTS];
  };
  
 -#define QUEUE_FLAG_STOPPED	1	/* queue is stopped */
 -#define QUEUE_FLAG_DYING	2	/* queue being torn down */
 -#define QUEUE_FLAG_NOMERGES     5	/* disable merge attempts */
 -#define QUEUE_FLAG_SAME_COMP	6	/* complete on same CPU-group */
 -#define QUEUE_FLAG_FAIL_IO	7	/* fake timeout */
 -#define QUEUE_FLAG_NONROT	9	/* non-rotational device (SSD) */
 -#define QUEUE_FLAG_VIRT        QUEUE_FLAG_NONROT /* paravirt device */
 -#define QUEUE_FLAG_IO_STAT     10	/* do disk/partitions IO accounting */
 -#define QUEUE_FLAG_DISCARD     11	/* supports DISCARD */
 -#define QUEUE_FLAG_NOXMERGES   12	/* No extended merges */
 -#define QUEUE_FLAG_ADD_RANDOM  13	/* Contributes to random pool */
 -#define QUEUE_FLAG_SECERASE    14	/* supports secure erase */
 -#define QUEUE_FLAG_SAME_FORCE  15	/* force complete on same CPU */
 -#define QUEUE_FLAG_DEAD        16	/* queue tear-down finished */
 -#define QUEUE_FLAG_INIT_DONE   17	/* queue is initialized */
 -#define QUEUE_FLAG_NO_SG_MERGE 18	/* don't attempt to merge SG segments*/
 -#define QUEUE_FLAG_POLL	       19	/* IO polling enabled if set */
 -#define QUEUE_FLAG_WC	       20	/* Write back caching */
 -#define QUEUE_FLAG_FUA	       21	/* device supports FUA writes */
 -#define QUEUE_FLAG_FLUSH_NQ    22	/* flush not queueuable */
 -#define QUEUE_FLAG_DAX         23	/* device supports DAX */
 -#define QUEUE_FLAG_STATS       24	/* track IO start and completion times */
 -#define QUEUE_FLAG_POLL_STATS  25	/* collecting stats for hybrid polling */
 -#define QUEUE_FLAG_REGISTERED  26	/* queue has been registered to a disk */
 -#define QUEUE_FLAG_SCSI_PASSTHROUGH 27	/* queue supports SCSI commands */
 -#define QUEUE_FLAG_QUIESCED    28	/* queue has been quiesced */
 -#define QUEUE_FLAG_PCI_P2PDMA  29	/* device supports PCI p2p requests */
 -
 -#define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
 -				 (1 << QUEUE_FLAG_SAME_COMP)	|	\
 -				 (1 << QUEUE_FLAG_ADD_RANDOM))
 +#define QUEUE_FLAG_STOPPED	0	/* queue is stopped */
 +#define QUEUE_FLAG_DYING	1	/* queue being torn down */
- #define QUEUE_FLAG_BIDI		2	/* queue supports bidi requests */
 +#define QUEUE_FLAG_NOMERGES     3	/* disable merge attempts */
 +#define QUEUE_FLAG_SAME_COMP	4	/* complete on same CPU-group */
 +#define QUEUE_FLAG_FAIL_IO	5	/* fake timeout */
 +#define QUEUE_FLAG_NONROT	6	/* non-rotational device (SSD) */
 +#define QUEUE_FLAG_VIRT		QUEUE_FLAG_NONROT /* paravirt device */
 +#define QUEUE_FLAG_IO_STAT	7	/* do disk/partitions IO accounting */
 +#define QUEUE_FLAG_DISCARD	8	/* supports DISCARD */
 +#define QUEUE_FLAG_NOXMERGES	9	/* No extended merges */
 +#define QUEUE_FLAG_ADD_RANDOM	10	/* Contributes to random pool */
 +#define QUEUE_FLAG_SECERASE	11	/* supports secure erase */
 +#define QUEUE_FLAG_SAME_FORCE	12	/* force complete on same CPU */
 +#define QUEUE_FLAG_DEAD		13	/* queue tear-down finished */
 +#define QUEUE_FLAG_INIT_DONE	14	/* queue is initialized */
 +#define QUEUE_FLAG_NO_SG_MERGE	15	/* don't attempt to merge SG segments*/
 +#define QUEUE_FLAG_POLL		16	/* IO polling enabled if set */
 +#define QUEUE_FLAG_WC		17	/* Write back caching */
 +#define QUEUE_FLAG_FUA		18	/* device supports FUA writes */
 +#define QUEUE_FLAG_DAX		19	/* device supports DAX */
 +#define QUEUE_FLAG_STATS	20	/* track IO start and completion times */
 +#define QUEUE_FLAG_POLL_STATS	21	/* collecting stats for hybrid polling */
 +#define QUEUE_FLAG_REGISTERED	22	/* queue has been registered to a disk */
 +#define QUEUE_FLAG_SCSI_PASSTHROUGH 23	/* queue supports SCSI commands */
 +#define QUEUE_FLAG_QUIESCED	24	/* queue has been quiesced */
 +#define QUEUE_FLAG_PCI_P2PDMA	25	/* device supports PCI p2p requests */
  
  #define QUEUE_FLAG_MQ_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
  				 (1 << QUEUE_FLAG_SAME_COMP))

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2016-11-11 19:55 ` Martin K. Petersen
@ 2016-11-17  2:44   ` Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2016-11-17  2:44 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig

Hi Martin,

On Fri, 11 Nov 2016 14:55:24 -0500 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
>
> In any case. It seems like the fact that the two SCSI trees may be out
> of sync could be an ongoing problem. So maybe you should just drop my
> tree again. I was just hoping to get visibility into potential merge
> problems sooner...

I'll keep it for now and see how it goes ...

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
  2016-11-09  2:54 Stephen Rothwell
@ 2016-11-11 19:55 ` Martin K. Petersen
  2016-11-17  2:44   ` Stephen Rothwell
  0 siblings, 1 reply; 13+ messages in thread
From: Martin K. Petersen @ 2016-11-11 19:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Martin K. Petersen, Jens Axboe, linux-next, linux-kernel,
	Christoph Hellwig

>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:

Stephen,

Stephen> This latter commit also exists as commit 2266d5678ad1 in the
Stephen> scsi tree, but unfortunately, the scsi-mkp tree was rebased
Stephen> overnight, so now the two patches are not the same commit :-( A
Stephen> significant path of what was rebased overnight has already been
Stephen> merged into the scsi tree ... so please tidy up your tree WRT
Stephen> the scsi tree.  This conflict would not exist if the rebase had
Stephen> not been done.

James' tree is usually a week or two behind mine. I almost never rebase
mid-cycle but in this case we had a data corruption bug fix that went to
Linus for 4.9 that a driver update depended on.

In any case. It seems like the fact that the two SCSI trees may be out
of sync could be an ongoing problem. So maybe you should just drop my
tree again. I was just hoping to get visibility into potential merge
problems sooner...

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 13+ messages in thread

* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2016-11-09  2:54 Stephen Rothwell
  2016-11-11 19:55 ` Martin K. Petersen
  0 siblings, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2016-11-09  2:54 UTC (permalink / raw)
  To: Martin K. Petersen, Jens Axboe
  Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Martin,

Today's linux-next merge of the scsi-mkp tree got conflicts in:

  drivers/scsi/ufs/ufshcd.c

between commit:

  e806402130c9 ("block: split out request-only flags into a new namespace")

from the block tree and commit:

  dcea0bfbc4cb ("scsi: ufs: fix sense buffer size to 18 bytes")

from the scsi-mkp tree.

This latter commit also exists as commit 2266d5678ad1 in the scsi tree,
but unfortunately, the scsi-mkp tree was rebased overnight, so now the
two patches are not the same commit :-(  A significant path of what was
rebased overnight has already been merged into the scsi tree ... so
please tidy up your tree WRT the scsi tree.  This conflict would not
exist if the rebase had not been done.

I fixed it up (it is also fixed in the scsi tree merge and so just
taking that version of the resolution works) 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2024-04-18  5:57 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-26  5:47 linux-next: manual merge of the scsi-mkp tree with the block tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-04-18  4:55 Stephen Rothwell
2024-04-18  5:57 ` Christoph Hellwig
2022-02-21 22:06 broonie
2022-03-01  7:29 ` Stephen Rothwell
2022-02-21 21:59 broonie
2022-02-22  5:57 ` Jinpu Wang
2022-03-01  7:31 ` Stephen Rothwell
2021-01-27  6:58 Stephen Rothwell
2019-02-11  4:23 Stephen Rothwell
2016-11-09  2:54 Stephen Rothwell
2016-11-11 19:55 ` Martin K. Petersen
2016-11-17  2:44   ` Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).