On Tue, May 10, 2016 at 6:00 PM, James Bottomley <jejb@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2016-05-10 at 17:46 +0200, Jinpu Wang wrote: >> On Tue, May 10, 2016 at 5:08 PM, James Bottomley >> <jejb@xxxxxxxxxxxxxxxxxx> wrote: > [...] >> > Actually, I think this is symptomatic of a much bigger problem. >> > Now that the FS can send zero length non BLOCK_PC request, we're >> > not treating failure correctly. blk_update_request() will always >> > finish them becuase they have no bytes outstanding (not having any >> > in the first case). So I think we need a special exception for all >> > zero length commands which complete with a failure to allow them to >> > retry (if required). >> >> Which request do you mean, I only find FLUSH? > > Flush is the only one currently, but zero length fs requests didn't > exist when this bit of SCSI was coded, which is why all the code judges > request completion on have we completed all the bytes (which is > obviously true if you had no bytes to send in the first place). > >> I will test your patch. > > Thanks. > > James > >> Thanks, >> Jack >> >> > >> > James >> > >> > --- >> > >> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >> > index 8106515..5a97866 100644 >> > --- a/drivers/scsi/scsi_lib.c >> > +++ b/drivers/scsi/scsi_lib.c >> > @@ -911,9 +911,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, >> > unsigned int good_bytes) >> > } >> > >> > /* >> > - * If we finished all bytes in the request we are done now. >> > + * special case: failed zero length commands always need to >> > + * drop down into the retry code. Otherwise, if we finished >> > + * all bytes in the request we are done now. >> > */ >> > - if (!scsi_end_request(req, error, good_bytes, 0)) >> > + if (!(good_bytes == 0 && blk_rq_bytes(req) == 0 && result >> > != 0) && >> > + !scsi_end_request(req, error, good_bytes, 0)) >> > return; >> > >> > /* >> > >> >> >> > Hi James, Your patch also fix the error for me. I'm also thinking a patch like this. :) Could you send out a formal patch, you can add my Tested-by. Regards, Jack -- 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
