On Mon, 11 May 2009 14:31:41 +0300
Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> >>> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
> >>> index 3da02e4..6605ec9 100644
> >>> --- a/drivers/scsi/libsas/sas_expander.c
> >>> +++ b/drivers/scsi/libsas/sas_expander.c
> >>> @@ -1936,12 +1936,8 @@ int sas_smp_handler(struct Scsi_Host *shost, struct sas_rphy *rphy,
> >>> bio_data(rsp->bio), rsp->data_len);
> >>> if (ret > 0) {
> >>> /* positive number is the untransferred residual */
> >>> - rsp->data_len = ret;
> >>> - req->data_len = 0;
> >>> + rsp->resid_len = ret;
> >>> ret = 0;
> >>> - } else if (ret == 0) {
> >>> - rsp->data_len = 0;
> >>> - req->data_len = 0;
> >>> }
> >>>
> >>> return ret;
> >> This is actually a bug fix, as well as a strait conversion
> >
> > Can you elaborate a bit about the bug fix part?
> >
>
> Nothing big really, just that before (according to the comment), the theoretical
> negative case would be full-residual. and now it is zero (untouched).
>
> I know that in iscsi a negative residual is possible which means over-flow. That is:
> the target had more data to give then the buffer had space for. (which is not an error at all)
Hmm, iSCSI? This code is for SAS management Protocol.
smp_execute_task returns a negative value for some errors (ENOMEM, the
hardware doesn't respond, etc). It's not related with 'transferred
buffer length' at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
