All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Smart <James.Smart@Emulex.Com>
Cc: Sven Schuetz <sven@linux.vnet.ibm.com>,
	Seokmann Ju <seokmann.ju@qlogic.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Andrew Vasquez <andrew.vasquez@qlogic.com>,
	"futjita.tomonori@lab.ntt.co.jp" <futjita.tomonori@lab.ntt.co.jp>,
	Giridhar Malavali <giridhar.malavali@qlogic.com>
Subject: Re: [RFC] FC pass thru - Rev V
Date: Sun, 15 Mar 2009 18:15:57 +0200	[thread overview]
Message-ID: <49BD29BD.9020101@panasas.com> (raw)
In-Reply-To: <49BD1B9E.4010804@emulex.com>

James Smart wrote:
> 
> Boaz Harrosh wrote:
> <snip..>
>>> +	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);
>>> +	}
>>> +
>>> +	/* we assume all request payload was transferred */
>> -	/* we assume all request payload was transferred */
>> +	/* we assume all request payload was transferred, residual == 0 */
>> +	req->data_len = 0;
>>
>> Note: this is the proper procedure. Otherwise bsg user will receive transfer
>> residual of all payload. On the other hand you might have more precise residual
>> information here, as received from the scsi transport? (Specially in the error
>> case, perhaps in the future).
>>
>>> +	blk_end_request(req, err, blk_rq_bytes(req));
>> -	blk_end_request(req, err, blk_rq_bytes(req));
>> +	blk_end_bidi_request(req, err, req_len, rsp_len);
>>
>>> +
>>> +	fc_destroy_bsgjob(job);
>>> +}
>> This should take care of all possible cases, (bidi or otherwise), and will
>> return the proper transfer residual count of 0 to user-mode.
> 
> We should be calling blk_end_bidi_request() even in cases where there wasn't a 
> req->next_rq ?
> 
> Here's what I would have done. Has your changes for setting req_len and 
> req->data_len, and Seokman's mods for calling either blk_end_bidi_request() or 
> blk_end_request() depending on whether there is a rsp request.
> 
> -- james s
> 
> 
> /**
>   * fc_bsg_jobdone - completion routine for bsg requests that the LLD has
>   *                  completed
>   * @job:	fc_bsg_job that is complete
>   */
> static void
> 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);
> 	job->state_flags |= FC_RQST_STATE_DONE;
> 	job->ref_cnt--;
> 	spin_unlock_irqrestore(&job->job_lock, flags);
> 
> 	err = job->req->errors = job->reply->result;
> 	if (err < 0)
> 		/* we're only returning the result field in the reply */
> 		job->req->sense_len = sizeof(uint32_t);
> 	else
> 		job->req->sense_len = job->reply_len;
> 
> 	/* we assume all request payload was transferred, residual == 0 */
> 	req->data_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);
> 		blk_end_bidi_request(req, err, req_len, rsp_len);
> 	} else
> 		blk_end_request(req, err, req_len);
> 
> 	fc_destroy_bsgjob(job);
> }

No! Please most certainly don't. this is the all issue here. blk_end_request
is just a wrapper for an internal blk_end_bidi_request(). They are essentially
the same exact call when the first just puts a zero at bidi_bytes.

My code is the preferred and easiest and most correct way. Again calling
blk_end_bidi_request() is absolutely always safe, only thing missing is a proper
comment for blk_end_bidi_request() that says so.

Cheers
Boaz

  reply	other threads:[~2009-03-15 16:18 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18 21:24 [RFC] FC pass thru - Rev IV James Smart
2008-11-24 15:46 ` Sven Schuetz
2008-11-24 16:29   ` James Smart
2008-11-25 15:08     ` Sven Schuetz
2008-11-25 15:56       ` James Smart
2008-11-24 20:37 ` Seokmann Ju
2008-11-24 21:03   ` James Smart
2008-11-25 14:38     ` Seokmann Ju
2008-11-25 15:47       ` James Smart
2008-12-01 21:49       ` Seokmann Ju
2008-12-01 22:09         ` James Smart
2008-11-26 18:25 ` Sven Schuetz
2008-11-26 18:58   ` James Smart
2008-11-27  7:03 ` FUJITA Tomonori
2008-11-27  8:58   ` Boaz Harrosh
2008-11-27  9:53     ` FUJITA Tomonori
2008-11-27 11:51       ` Boaz Harrosh
2008-11-28  1:52         ` FUJITA Tomonori
2008-11-30 10:56           ` Boaz Harrosh
2008-11-28  2:01       ` James Bottomley
2008-11-28  2:22         ` FUJITA Tomonori
2009-02-11 15:13 ` [RFC] FC pass thru - Rev V James Smart
2009-02-11 15:43   ` Seokmann Ju
2009-02-20  2:33     ` Seokmann Ju
2009-02-20 18:53       ` James Smart
2009-02-21  6:00       ` FUJITA Tomonori
2009-02-24 14:25         ` Seokmann Ju
2009-03-13 16:25     ` Seokmann Ju
2009-03-13 16:47       ` Sven Schuetz
2009-03-13 17:04         ` Seokmann Ju
2009-03-15  9:34         ` Boaz Harrosh
2009-03-15 13:14           ` James Smart
2009-03-15 14:03             ` Boaz Harrosh
2009-03-15 15:15               ` James Smart
2009-03-15 16:15                 ` Boaz Harrosh [this message]
2009-03-15 14:26             ` Boaz Harrosh
2009-03-19  1:57           ` FUJITA Tomonori
2009-03-14 22:16       ` James Smart
2009-03-16 11:36         ` Seokmann Ju
2009-03-25 12:58         ` Seokmann Ju
2009-03-15  9:30       ` Boaz Harrosh
2009-03-16 11:40         ` Seokmann Ju
2009-03-16 13:38           ` Boaz Harrosh
2009-03-16 15:37             ` Seokmann Ju
2009-02-11 16:15   ` Boaz Harrosh
2009-02-11 16:33     ` FUJITA Tomonori
2009-02-11 16:55       ` Boaz Harrosh
2009-02-11 17:14         ` FUJITA Tomonori
2009-02-11 18:16           ` Boaz Harrosh
2009-03-07 12:17   ` Seokmann Ju
2009-03-07 14:44     ` James Smart
2009-03-07 20:18       ` Seokmann Ju
2009-03-08 15:00         ` James Smart
2009-03-08 15:46           ` Boaz Harrosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49BD29BD.9020101@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Smart@Emulex.Com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=futjita.tomonori@lab.ntt.co.jp \
    --cc=giridhar.malavali@qlogic.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=seokmann.ju@qlogic.com \
    --cc=sven@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.