[PATCH] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[PATCH] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

Hi Stephen below is the correct patch for the scsi-misc build
failure when merged after block/for-next branch.
(Note that current linux-next fix will not work)

Tejun please review?

James, I still think the easiest is to squash this into
The FC Pass Thru support patch and put it in a post-merge
tree.
---
From: Boaz Harrosh <bharrosh@panasas.com>
Subject: [PATCH] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

This patch should be squashed into:
    [SCSI] FC Pass Thru support

If it needs to compile after Tejun's block-layer revamps

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
 drivers/scsi/scsi_transport_fc.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 4df8c3c..41c90fe 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -3409,7 +3409,6 @@ fc_bsg_jobdone(struct fc_bsg_job *job)
 	struct request *req = job->req;
 	struct request *rsp = req->next_rq;
 	unsigned long flags;
-	unsigned rsp_len = 0, req_len = blk_rq_bytes(req);
 	int err;
 
 	spin_lock_irqsave(&job->job_lock, flags);
@@ -3425,16 +3424,15 @@ fc_bsg_jobdone(struct fc_bsg_job *job)
 		job->req->sense_len = job->reply_len;
 
 	/* we assume all request payload was transferred, residual == 0 */
-	req->data_len = 0;
+	req->resid_len = 0;
 
 	if (rsp) {
-		rsp_len = blk_rq_bytes(rsp);
-		BUG_ON(job->reply->reply_payload_rcv_len > rsp_len);
 		/* set reply (bidi) residual */
-		rsp->data_len = (rsp_len - job->reply->reply_payload_rcv_len);
+		rsp->resid_len = blk_rq_bytes(rsp) -
+					job->reply->reply_payload_rcv_len;
 	}
 
-	blk_end_bidi_request(req, err, req_len, rsp_len);
+	blk_end_request_all(req, err);
 
 	fc_destroy_bsgjob(job);
 }
@@ -3496,7 +3494,7 @@ fc_bsg_map_buffer(struct fc_bsg_buffer *buf, struct request *req)
 		return -ENOMEM;
 	sg_init_table(buf->sg_list, req->nr_phys_segments);
 	buf->sg_cnt = blk_rq_map_sg(req->q, req, buf->sg_list);
-	buf->payload_len = req->data_len;
+	buf->payload_len = blk_rq_bytes(req);
 	return 0;
 }
 
@@ -3762,14 +3760,12 @@ fc_bsg_request_handler(struct request_queue *q, struct Scsi_Host *shost,
 		return;
 
 	while (!blk_queue_plugged(q)) {
-		req = elv_next_request(q);
-		if (!req)
-			break;
-
 		if (rport && (rport->port_state == FC_PORTSTATE_BLOCKED))
 				break;
 
-		blkdev_dequeue_request(req);
+		req = blk_fetch_request(q);
+		if (!req)
+			break;
 
 		if (rport && (rport->port_state != FC_PORTSTATE_ONLINE)) {
 			req->errors = -ENXIO;
-- 
1.6.2.1

Re: [PATCH] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Tejun Heo]

Hello, Boaz.

Just two minor things.

Boaz Harrosh wrote:
>  	/* we assume all request payload was transferred, residual == 0 */
> -	req->data_len = 0;
> +	req->resid_len = 0;
>  
>  	if (rsp) {
> -		rsp_len = blk_rq_bytes(rsp);
> -		BUG_ON(job->reply->reply_payload_rcv_len > rsp_len);

Maybe convert it to WARN_ON() instead of removing?

>  		/* set reply (bidi) residual */
> -		rsp->data_len = (rsp_len - job->reply->reply_payload_rcv_len);
> +		rsp->resid_len = blk_rq_bytes(rsp) -
> +					job->reply->reply_payload_rcv_len;

With the fix-fallouts patchset it, this can be

	rsp->resid_len -= job->reply->reply_payload_rcv_len;

Other than above misc points,

Acked-by: Tejun Heo <tj@kernel.org>

-- 
tejun

Re: [PATCH] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/19/2009 01:05 PM, Tejun Heo wrote:
> Hello, Boaz.
> 
> Just two minor things.
> 
> Boaz Harrosh wrote:
>>  	/* we assume all request payload was transferred, residual == 0 */
>> -	req->data_len = 0;
>> +	req->resid_len = 0;
>>  
>>  	if (rsp) {
>> -		rsp_len = blk_rq_bytes(rsp);
>> -		BUG_ON(job->reply->reply_payload_rcv_len > rsp_len);
> 
> Maybe convert it to WARN_ON() instead of removing?

Sorry, You are absolutely correct should add it back. (With a WARN_ON)

> 
>>  		/* set reply (bidi) residual */
>> -		rsp->data_len = (rsp_len - job->reply->reply_payload_rcv_len);
>> +		rsp->resid_len = blk_rq_bytes(rsp) -
>> +					job->reply->reply_payload_rcv_len;
> 
> With the fix-fallouts patchset it, this can be
> 
> 	rsp->resid_len -= job->reply->reply_payload_rcv_len;
> 

Sure.

> Other than above misc points,
> 
> Acked-by: Tejun Heo <tj@kernel.org>
> 

Will repost as reply to Original patch, thanks
Boaz

[PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

This patch should be squashed into
    [SCSI] FC Pass Thru support

If it needs to compile after Tejun's block-layer revamps
(all of them)

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Acked-by: Tejun Heo <tj@kernel.org>
---
 drivers/scsi/scsi_transport_fc.c |   22 ++++++++++------------
 1 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 4df8c3c..809b75c 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -3409,7 +3409,6 @@ fc_bsg_jobdone(struct fc_bsg_job *job)
 	struct request *req = job->req;
 	struct request *rsp = req->next_rq;
 	unsigned long flags;
-	unsigned rsp_len = 0, req_len = blk_rq_bytes(req);
 	int err;
 
 	spin_lock_irqsave(&job->job_lock, flags);
@@ -3425,16 +3424,17 @@ fc_bsg_jobdone(struct fc_bsg_job *job)
 		job->req->sense_len = job->reply_len;
 
 	/* we assume all request payload was transferred, residual == 0 */
-	req->data_len = 0;
+	req->resid_len = 0;
 
 	if (rsp) {
-		rsp_len = blk_rq_bytes(rsp);
-		BUG_ON(job->reply->reply_payload_rcv_len > rsp_len);
+		WARN_ON(job->reply->reply_payload_rcv_len > rsp->resid_len);
+
 		/* set reply (bidi) residual */
-		rsp->data_len = (rsp_len - job->reply->reply_payload_rcv_len);
+		rsp->resid_len -= min(job->reply->reply_payload_rcv_len, 
+				      rsp->resid_len);
 	}
 
-	blk_end_bidi_request(req, err, req_len, rsp_len);
+	blk_end_request_all(req, err);
 
 	fc_destroy_bsgjob(job);
 }
@@ -3496,7 +3496,7 @@ fc_bsg_map_buffer(struct fc_bsg_buffer *buf, struct request *req)
 		return -ENOMEM;
 	sg_init_table(buf->sg_list, req->nr_phys_segments);
 	buf->sg_cnt = blk_rq_map_sg(req->q, req, buf->sg_list);
-	buf->payload_len = req->data_len;
+	buf->payload_len = blk_rq_bytes(req);
 	return 0;
 }
 
@@ -3762,14 +3762,12 @@ fc_bsg_request_handler(struct request_queue *q, struct Scsi_Host *shost,
 		return;
 
 	while (!blk_queue_plugged(q)) {
-		req = elv_next_request(q);
-		if (!req)
-			break;
-
 		if (rport && (rport->port_state == FC_PORTSTATE_BLOCKED))
 				break;
 
-		blkdev_dequeue_request(req);
+		req = blk_fetch_request(q);
+		if (!req)
+			break;
 
 		if (rport && (rport->port_state != FC_PORTSTATE_ONLINE)) {
 			req->errors = -ENXIO;
-- 
1.6.2.1

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Stephen Rothwell]

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

On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
>
> 
> This patch should be squashed into
>     [SCSI] FC Pass Thru support
> 
> If it needs to compile after Tejun's block-layer revamps
> (all of them)

Is there some reason that the FC passthrough support (and any followup
patches) can't be pushed through the block tree.  It clearly currently
doesn't depend on anything new in the scsi tree ...

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

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

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/20/2009 04:16 AM, Stephen Rothwell wrote:
> On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
>>
>> This patch should be squashed into
>>     [SCSI] FC Pass Thru support
>>
>> If it needs to compile after Tejun's block-layer revamps
>> (all of them)
> 
> Is there some reason that the FC passthrough support (and any followup
> patches) can't be pushed through the block tree.  It clearly currently
> doesn't depend on anything new in the scsi tree ...
> 

If it will go through block tree it needs James Bottomley's Ack, I
guess?

It does, in any case, need Ack from James Smart first. James ?

Thanks
Boaz

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Smart]

Fine by me.

-- james s

Acked-by: James Smart <james.smart@emulex.com>


Boaz Harrosh wrote:
> On 05/20/2009 04:16 AM, Stephen Rothwell wrote:
>   
>> On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
>>     
>>> This patch should be squashed into
>>>     [SCSI] FC Pass Thru support
>>>
>>> If it needs to compile after Tejun's block-layer revamps
>>> (all of them)
>>>       
>> Is there some reason that the FC passthrough support (and any followup
>> patches) can't be pushed through the block tree.  It clearly currently
>> doesn't depend on anything new in the scsi tree ...
>>
>>     
>
> If it will go through block tree it needs James Bottomley's Ack, I
> guess?
>
> It does, in any case, need Ack from James Smart first. James ?
>
> Thanks
> Boaz
>
>   

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Bottomley]

On Wed, 2009-05-20 at 11:16 +1000, Stephen Rothwell wrote:
> On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
> >
> > 
> > This patch should be squashed into
> >     [SCSI] FC Pass Thru support
> > 
> > If it needs to compile after Tejun's block-layer revamps
> > (all of them)
> 
> Is there some reason that the FC passthrough support (and any followup
> patches) can't be pushed through the block tree.  It clearly currently
> doesn't depend on anything new in the scsi tree ...

That would preserve the logical sequence of patches, yes.  However, Jens
is a bit pressed for time, so I agreed to do this in SCSI.

Unfortuantely, I still need the block tree for-next to be rebased up to
the current linus head because of a couple of conflicts:

CONFLICT (content): Merge conflict in drivers/block/hd.c
CONFLICT (content): Merge conflict in drivers/block/mg_disk.c

The are both just rebase/rebase conflicts:  it looks like there are two
commit ids for 

commit 0191944282e84931f92915b5f06b348a92dac7e1
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Apr 28 12:38:33 2009 +0900

    hd: fix locking

commit 7090a0a97f55cbf47547a140fcc5a349f32c598c
Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date:   Tue Apr 28 12:38:33 2009 +0900

    mg_disk: fix CONFIG_LBD=y warning
 
commit ac2ff946a53e7bd0ae98f4e5d1d6c1b1dced82e5
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Apr 28 12:38:32 2009 +0900

    mg_disk: fix locking

 
So they obviously moved into linus head but wasn't taken out of block
for-next.

James

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Stephen Rothwell]

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

Hi James,

On Wed, 20 May 2009 14:37:20 +0000 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> Unfortuantely, I still need the block tree for-next to be rebased up to
> the current linus head because of a couple of conflicts:
> 
> CONFLICT (content): Merge conflict in drivers/block/hd.c
> CONFLICT (content): Merge conflict in drivers/block/mg_disk.c

As discussed elsewhere, a merge of Linus' tree into the block tree will
fix this.

> So they obviously moved into linus head but wasn't taken out of block
> for-next.

Indeed.

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

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

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Bottomley]

On Thu, 2009-05-21 at 00:42 +1000, Stephen Rothwell wrote:
> Hi James,
> 
> On Wed, 20 May 2009 14:37:20 +0000 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >
> > Unfortuantely, I still need the block tree for-next to be rebased up to
> > the current linus head because of a couple of conflicts:
> > 
> > CONFLICT (content): Merge conflict in drivers/block/hd.c
> > CONFLICT (content): Merge conflict in drivers/block/mg_disk.c
> 
> As discussed elsewhere, a merge of Linus' tree into the block tree will
> fix this.

Yes, I know, I was just adding urgency because scsi-misc has the two
conflicting commits in it, so it can't be merged into block for-next.

> > So they obviously moved into linus head but wasn't taken out of block
> > for-next.
> 
> Indeed.

OK, so I think your pulling of my posmerge tree can cope with the fact
that I did the necessary rebasing in block for-next before I made it the
base of my combined tree .... think of this as a nice test.

Just building now ... if it works, I'll push to SCSI post merge and all
our problems should go away.

James

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Bottomley]

On Wed, 2009-05-20 at 14:47 +0000, James Bottomley wrote:
> OK, so I think your pulling of my posmerge tree can cope with the fact
> that I did the necessary rebasing in block for-next before I made it the
> base of my combined tree .... think of this as a nice test.
> 
> Just building now ... if it works, I'll push to SCSI post merge and all
> our problems should go away.

Unfortunately the combined tree hits a BUG_ON blk-core.c:2045 when doing
SPI domain validation.

There will be a short delay ...

James

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/20/2009 07:20 PM, James Bottomley wrote:
> On Wed, 2009-05-20 at 14:47 +0000, James Bottomley wrote:
>> OK, so I think your pulling of my posmerge tree can cope with the fact
>> that I did the necessary rebasing in block for-next before I made it the
>> base of my combined tree .... think of this as a nice test.
>>
>> Just building now ... if it works, I'll push to SCSI post merge and all
>> our problems should go away.
> 
> Unfortunately the combined tree hits a BUG_ON blk-core.c:2045 when doing
> SPI domain validation.
> 
> There will be a short delay ...
> 
> James
> 
> 

I have rebased block/for-next onto linus/master which should give us the
same content?

But line 2045 is on a code comment.

if I now do a git-log v2.6.30-rc3..HEAD I have the following patches:
pick 42dad76 block: simplify I/O stat accounting
pick af498d7 block: fix the bio_vec array index out-of-bounds test
pick d616ee5 block: clear req->errors on bio completion only for fs requests
pick 268ea3d block: merge blk_invoke_request_fn() into __blk_run_queue()
pick d097b7d block: kill blk_start_queueing()
pick 3099167 block: don't set REQ_NOMERGE unnecessarily
pick 4095018 block: cleanup REQ_SOFTBARRIER usages
pick 17fc349 block: reorder request completion functions
pick 6e6732a block: reorganize request fetching functions
pick ca219b4 block: kill blk_end_request_callback()
pick ea1e706 block: clean up request completion API
pick 70a8607 block: move rq->start_time initialization to blk_rq_init()
pick fa6e42b block: implement and use [__]blk_end_request_all()
pick 861af79 block: kill rq->data
pick 6abeea3 block: make blk_do_io_stat() do the full "is this rq accountable" checks
pick 2f94129 block: catch trying to use more bits than request->cmd_flags has
pick 325f440 block: implement blk_rq_pos/[cur_]sectors() and convert obvious ones
pick 7168ea4 block: convert to pos and nr_sectors accessors
pick 209e1e4 block: drop request->hard_* and *nr_sectors
pick 80d23d0 block: hide request sector and data_len
pick 563e977 block: implement and enforce request peek/start/fetch
pick 6cd0982 block: move completion related functions back to blk-core.c
pick 3978c4e block: set rq->resid_len to blk_rq_bytes() on issue
pick 01f54fd block: Add blk_make_request(), takes bio, returns a request
pick 0d58792 block: add warning to blk_make_request()

How did you resolve the block/for-next and linus/master merge?

Thanks
Boaz

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/20/2009 07:39 PM, Boaz Harrosh wrote:
> On 05/20/2009 07:20 PM, James Bottomley wrote:
>> On Wed, 2009-05-20 at 14:47 +0000, James Bottomley wrote:
>>> OK, so I think your pulling of my posmerge tree can cope with the fact
>>> that I did the necessary rebasing in block for-next before I made it the
>>> base of my combined tree .... think of this as a nice test.
>>>
>>> Just building now ... if it works, I'll push to SCSI post merge and all
>>> our problems should go away.
>> Unfortunately the combined tree hits a BUG_ON blk-core.c:2045 when doing
>> SPI domain validation.
>>
>> There will be a short delay ...
>>
>> James
>>
>>
> 
> I have rebased block/for-next onto linus/master which should give us the
> same content?
> 
> But line 2045 is on a code comment.
> 
> if I now do a git-log v2.6.30-rc3..HEAD I have the following patches:

for blk-core.c that is

> pick 42dad76 block: simplify I/O stat accounting
> pick af498d7 block: fix the bio_vec array index out-of-bounds test
> pick d616ee5 block: clear req->errors on bio completion only for fs requests
> pick 268ea3d block: merge blk_invoke_request_fn() into __blk_run_queue()
> pick d097b7d block: kill blk_start_queueing()
> pick 3099167 block: don't set REQ_NOMERGE unnecessarily
> pick 4095018 block: cleanup REQ_SOFTBARRIER usages
> pick 17fc349 block: reorder request completion functions
> pick 6e6732a block: reorganize request fetching functions
> pick ca219b4 block: kill blk_end_request_callback()
> pick ea1e706 block: clean up request completion API
> pick 70a8607 block: move rq->start_time initialization to blk_rq_init()
> pick fa6e42b block: implement and use [__]blk_end_request_all()
> pick 861af79 block: kill rq->data
> pick 6abeea3 block: make blk_do_io_stat() do the full "is this rq accountable" checks
> pick 2f94129 block: catch trying to use more bits than request->cmd_flags has
> pick 325f440 block: implement blk_rq_pos/[cur_]sectors() and convert obvious ones
> pick 7168ea4 block: convert to pos and nr_sectors accessors
> pick 209e1e4 block: drop request->hard_* and *nr_sectors
> pick 80d23d0 block: hide request sector and data_len
> pick 563e977 block: implement and enforce request peek/start/fetch
> pick 6cd0982 block: move completion related functions back to blk-core.c
> pick 3978c4e block: set rq->resid_len to blk_rq_bytes() on issue
> pick 01f54fd block: Add blk_make_request(), takes bio, returns a request
> pick 0d58792 block: add warning to blk_make_request()
> 
> How did you resolve the block/for-next and linus/master merge?
> 
> Thanks
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Bottomley]

On Wed, 2009-05-20 at 19:39 +0300, Boaz Harrosh wrote:
> On 05/20/2009 07:20 PM, James Bottomley wrote:
> > On Wed, 2009-05-20 at 14:47 +0000, James Bottomley wrote:
> >> OK, so I think your pulling of my posmerge tree can cope with the fact
> >> that I did the necessary rebasing in block for-next before I made it the
> >> base of my combined tree .... think of this as a nice test.
> >>
> >> Just building now ... if it works, I'll push to SCSI post merge and all
> >> our problems should go away.
> > 
> > Unfortunately the combined tree hits a BUG_ON blk-core.c:2045 when doing
> > SPI domain validation.
> > 
> > There will be a short delay ...
> > 
> > James
> > 
> > 
> 
> I have rebased block/for-next onto linus/master which should give us the
> same content?
> 
> But line 2045 is on a code comment.
> 
> if I now do a git-log v2.6.30-rc3..HEAD I have the following patches:
> pick 42dad76 block: simplify I/O stat accounting
> pick af498d7 block: fix the bio_vec array index out-of-bounds test
> pick d616ee5 block: clear req->errors on bio completion only for fs requests
> pick 268ea3d block: merge blk_invoke_request_fn() into __blk_run_queue()
> pick d097b7d block: kill blk_start_queueing()
> pick 3099167 block: don't set REQ_NOMERGE unnecessarily
> pick 4095018 block: cleanup REQ_SOFTBARRIER usages
> pick 17fc349 block: reorder request completion functions
> pick 6e6732a block: reorganize request fetching functions
> pick ca219b4 block: kill blk_end_request_callback()
> pick ea1e706 block: clean up request completion API
> pick 70a8607 block: move rq->start_time initialization to blk_rq_init()
> pick fa6e42b block: implement and use [__]blk_end_request_all()
> pick 861af79 block: kill rq->data
> pick 6abeea3 block: make blk_do_io_stat() do the full "is this rq accountable" checks
> pick 2f94129 block: catch trying to use more bits than request->cmd_flags has
> pick 325f440 block: implement blk_rq_pos/[cur_]sectors() and convert obvious ones
> pick 7168ea4 block: convert to pos and nr_sectors accessors
> pick 209e1e4 block: drop request->hard_* and *nr_sectors
> pick 80d23d0 block: hide request sector and data_len
> pick 563e977 block: implement and enforce request peek/start/fetch
> pick 6cd0982 block: move completion related functions back to blk-core.c
> pick 3978c4e block: set rq->resid_len to blk_rq_bytes() on issue
> pick 01f54fd block: Add blk_make_request(), takes bio, returns a request
> pick 0d58792 block: add warning to blk_make_request()
> 
> How did you resolve the block/for-next and linus/master merge?

I rebased on to the merge base of scsi-misc.

If you actually just ask scsi-post-merge-2.6 where this line is, it will
tell you:

static void blk_finish_request(struct request *req, int error)
{
        BUG_ON(blk_queued_rq(req));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

        if (blk_rq_tagged(req))
                blk_queue_end_tag(req->q, req);

James

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/20/2009 07:43 PM, James Bottomley wrote:
> If you actually just ask scsi-post-merge-2.6 where this line is, it will
> tell you:
> 
> static void blk_finish_request(struct request *req, int error)
> {
>         BUG_ON(blk_queued_rq(req));
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>         if (blk_rq_tagged(req))
>                 blk_queue_end_tag(req->q, req);
> 
> James
> 
> 

This is a new BUG_ON from:
    block: implement and enforce request peek/start/fetch

It looks like there is one more sight of the old usage that
was not converted.

Tejun?
 

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Boaz Harrosh]

On 05/20/2009 07:59 PM, Boaz Harrosh wrote:
> On 05/20/2009 07:43 PM, James Bottomley wrote:
>> If you actually just ask scsi-post-merge-2.6 where this line is, it will
>> tell you:
>>
>> static void blk_finish_request(struct request *req, int error)
>> {
>>         BUG_ON(blk_queued_rq(req));
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>         if (blk_rq_tagged(req))
>>                 blk_queue_end_tag(req->q, req);
>>
>> James
>>
>>
> 
> This is a new BUG_ON from:
>     block: implement and enforce request peek/start/fetch
> 
> It looks like there is one more sight of the old usage that
> was not converted.
> 
> Tejun?
>  

The patch has a comment about that:
    * disallowing completion of queued (not started) requests

Do you have a stack trace?

Boaz

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[James Bottomley]

On Wed, 2009-05-20 at 16:20 +0000, James Bottomley wrote:
> On Wed, 2009-05-20 at 14:47 +0000, James Bottomley wrote:
> > OK, so I think your pulling of my posmerge tree can cope with the fact
> > that I did the necessary rebasing in block for-next before I made it the
> > base of my combined tree .... think of this as a nice test.
> > 
> > Just building now ... if it works, I'll push to SCSI post merge and all
> > our problems should go away.
> 
> Unfortunately the combined tree hits a BUG_ON blk-core.c:2045 when doing
> SPI domain validation.
> 
> There will be a short delay ...

OK, delay resolved.  With the additional oops fix patch, the tree now
boots and checks out.  I've pushed it, so it should show up in the next
linux-next.

James

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Stephen Rothwell]

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

Hi James,

On Wed, 20 May 2009 14:37:20 +0000 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> That would preserve the logical sequence of patches, yes.  However, Jens
> is a bit pressed for time, so I agreed to do this in SCSI.

That is entirely up to you and Jens as the maintainers.  Someone will
just need to fix up the conflicts during the merge window.

Given the conflict resolution patch sent to me by Boaz, I can cope in
linux-next for now.

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

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

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Jens Axboe]

On Wed, May 20 2009, James Bottomley wrote:
> On Wed, 2009-05-20 at 11:16 +1000, Stephen Rothwell wrote:
> > On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
> > >
> > > 
> > > This patch should be squashed into
> > >     [SCSI] FC Pass Thru support
> > > 
> > > If it needs to compile after Tejun's block-layer revamps
> > > (all of them)
> > 
> > Is there some reason that the FC passthrough support (and any followup
> > patches) can't be pushed through the block tree.  It clearly currently
> > doesn't depend on anything new in the scsi tree ...
> 
> That would preserve the logical sequence of patches, yes.  However, Jens
> is a bit pressed for time, so I agreed to do this in SCSI.
> 
> Unfortuantely, I still need the block tree for-next to be rebased up to
> the current linus head because of a couple of conflicts:
> 
> CONFLICT (content): Merge conflict in drivers/block/hd.c
> CONFLICT (content): Merge conflict in drivers/block/mg_disk.c
> 
> The are both just rebase/rebase conflicts:  it looks like there are two
> commit ids for 

James, I'll get this fixed (either pull linus tree in or rebase) and
send you a note! It wont be before tomorrow, I think.

-- 
Jens Axboe

Re: [PATCH version 2] [SQUASHME] "FC Pass Thru support" fixed for block/for-2.6.31 tree

[Stephen Rothwell]

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

Hi Boaz,

On Tue, 19 May 2009 15:54:59 +0300 Boaz Harrosh <bharrosh@panasas.com> wrote:
>
> 
> This patch should be squashed into
>     [SCSI] FC Pass Thru support
> 
> If it needs to compile after Tejun's block-layer revamps
> (all of them)

I have used this as my merge fixup for today.  Thanks for that.

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

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