All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Boaz Harrosh <bharrosh@panasas.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Borislav Petkov <petkovbb@googlemail.com>,
	Pete Zaitcev <zaitcev@redhat.com>,
	Eric Moore <Eric.Moore@lsi.com>,
	"Darrick J. Wong" <djwong@us.ibm.com>
Subject: Re: [PATCH block#for-2.6.31 2/3] block: set rq->resid_len to blk_rq_bytes() on issue
Date: Fri, 15 May 2009 19:38:27 +0400	[thread overview]
Message-ID: <4A0D8C73.50208@ru.mvista.com> (raw)
In-Reply-To: <4A0D87D2.7090806@gmail.com>

Hello.

Tejun Heo wrote:

> In commit c3a4d78c580de4edc9ef0f7c59812fb02ceb037f, while introducing
> rq->resid_len, the default value of residue count was changed from
> full count to zero.  The conversion was done under the assumption that
> when a request fails residue count wasn't defined.  However, Boaz and
> James pointed out that this wasn't true and the residue count should
> be preserved for failed requests too.

> This patchset restores the original behavior by setting rq->resid_len
> to blk_rq_bytes(rq) on issue and restoring explicit clearing in
> affected drivers.  While at it, take advantage of the fact that
> rq->resid_len is set to full count where applicable.

> * ide-cd: rq->resid_len cleared on pc success

> * mptsas: req->resid_len cleared on success

> * sas_expander: rsp/req->resid_len cleared on success

> * mpt2sas_transport: req->resid_len cleared on success

> * ide-cd, ide-tape, mptsas, sas_host_smp, mpt2sas_transport, ub: take
>   advantage of initial full count to simplify code

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

    The patch looks er... strange at some places.

> Index: block/drivers/message/fusion/mptsas.c
> ===================================================================
> --- block.orig/drivers/message/fusion/mptsas.c
> +++ block/drivers/message/fusion/mptsas.c
> @@ -1357,7 +1357,8 @@ static int mptsas_smp_handler(struct Scs
>  		smprep = (SmpPassthroughReply_t *)ioc->sas_mgmt.reply;
>  		memcpy(req->sense, smprep, sizeof(*smprep));
>  		req->sense_len = sizeof(*smprep);
> -		rsp->resid_len = blk_rq_bytes(rsp) - smprep->ResponseDataLength;
> +		req->resid_len = 0;
> +		rsp->resid_len -= smprep->ResponseDataLength;

    Is negative resid_len intended here? If so, shouldn't it be simply:

		rsp->resid_len = -smprep->ResponseDataLength;


> Index: block/drivers/scsi/libsas/sas_expander.c
> ===================================================================
> --- block.orig/drivers/scsi/libsas/sas_expander.c
> +++ block/drivers/scsi/libsas/sas_expander.c
> @@ -1937,7 +1937,11 @@ int sas_smp_handler(struct Scsi_Host *sh
>  	if (ret > 0) {
>  		/* positive number is the untransferred residual */
>  		rsp->resid_len = ret;
> +		req->resid_len = 0;
>  		ret = 0;
> +	} else if (ret == 0) {
> +		rsp->resid_len = 0;
> +		req->resid_len = 0;

    ???

> Index: block/drivers/scsi/libsas/sas_host_smp.c
> ===================================================================
> --- block.orig/drivers/scsi/libsas/sas_host_smp.c
> +++ block/drivers/scsi/libsas/sas_host_smp.c
> @@ -176,9 +176,6 @@ int sas_smp_host_handler(struct Scsi_Hos
>  	resp_data[1] = req_data[1];
>  	resp_data[2] = SMP_RESP_FUNC_UNK;
>  
> -	req->resid_len = blk_rq_bytes(req);
> -	rsp->resid_len = blk_rq_bytes(rsp);
> -

    ???

>  	switch (req_data[1]) {
>  	case SMP_REPORT_GENERAL:
>  		req->resid_len -= 8;
> Index: block/drivers/scsi/mpt2sas/mpt2sas_transport.c
> ===================================================================
> --- block.orig/drivers/scsi/mpt2sas/mpt2sas_transport.c
> +++ block/drivers/scsi/mpt2sas/mpt2sas_transport.c
> @@ -1170,8 +1170,8 @@ transport_smp_handler(struct Scsi_Host *
>  
>  		memcpy(req->sense, mpi_reply, sizeof(*mpi_reply));
>  		req->sense_len = sizeof(*mpi_reply);
> -		rsp->resid_len = blk_rq_bytes(rsp) -
> -				 mpi_reply->ResponseDataLength;
> +		req->resid_len = 0;
> +		rsp->resid_len -= mpi_reply->ResponseDataLength;

    Again, is negative resid_len intended?

MBR, Sergei

  parent reply	other threads:[~2009-05-15 15:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 15:14 [PATCH block#for-2.6.31 1/3] ub: use __blk_end_request_all() Tejun Heo
2009-05-15 15:14 ` Tejun Heo
2009-05-15 15:18 ` [PATCH block#for-2.6.31 2/3] block: set rq->resid_len to blk_rq_bytes() on issue Tejun Heo
2009-05-15 15:18 ` Tejun Heo
2009-05-15 15:18   ` Tejun Heo
2009-05-15 15:19   ` [PATCH block#for-2.6.31 3/3] bio: always copy back data for copied kernel requests Tejun Heo
2009-05-15 15:19   ` Tejun Heo
2009-05-15 15:19   ` Tejun Heo
2009-05-15 15:38   ` Sergei Shtylyov [this message]
2009-05-15 22:18     ` [PATCH block#for-2.6.31 2/3] block: set rq->resid_len to blk_rq_bytes() on issue Tejun Heo
2009-05-16 12:29       ` Sergei Shtylyov
2009-05-16 13:48         ` Tejun Heo
2009-05-15 17:29   ` Pete Zaitcev
2009-05-15 22:14     ` Tejun Heo
2009-05-15 23:16       ` Pete Zaitcev
2009-05-16  0:14         ` Tejun Heo
2009-05-16  0:18   ` [PATCH UPDATED " Tejun Heo
2009-05-16  0:18   ` Tejun Heo
2009-05-16  0:18     ` Tejun Heo
2009-05-17  8:48     ` Boaz Harrosh
2009-05-17 11:32       ` Tejun Heo
2009-05-17 11:41         ` Tejun Heo
2009-05-17 12:05     ` [PATCH UPDATED2 " Tejun Heo
2009-05-17 12:05     ` Tejun Heo
2009-05-17 12:05       ` Tejun Heo
2009-05-18 12:49       ` Jens Axboe
2009-05-19  9:14         ` Tejun Heo
2009-05-19  9:17           ` Jens Axboe
2009-05-16  7:13   ` [PATCH " Borislav Petkov
2009-05-16 13:52     ` Tejun Heo
2009-05-16 13:52     ` Tejun Heo
2009-05-16 13:52       ` Tejun Heo
2009-05-15 17:31 ` [PATCH block#for-2.6.31 1/3] ub: use __blk_end_request_all() Pete Zaitcev
2009-05-15 22:19   ` Tejun Heo

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=4A0D8C73.50208@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=Eric.Moore@lsi.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=bzolnier@gmail.com \
    --cc=djwong@us.ibm.com \
    --cc=htejun@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=petkovbb@googlemail.com \
    --cc=zaitcev@redhat.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.