> >Sagi's patch was not correct because scsi_in was hardcoded to the transfer > >len when bidi was used. > > Right, should have condition that in the direction. something like: > > transfer_length = sc->sc_data_direction == DMA_TO_DEVICE ? > scsi_out(sc)->length : scsi_in(sc)->length; > > would probably hit that in testing before sending out a patch.
We could also pass the dma direction indeed. Compared to my suggestion of passing thr scsi_data_buffer this makes life a lot easier for drivers that don't try to support the bidi madness. > >There is one issue/question though. Is this working ok with LIO? I left > >scsi_transfer_length() with the same behavior as before assuming LIO was > >ok and only the iscsi initiator had suffered a regression. > > I think that if we go with scsi_in/out_transfer_length then > scsi_transfer_length should be removed > and LIO can be modified to use scsi_in/out_transfer_length. drivers/target/loopback/tcm_loop.c doesn't (and absolutely shouldn't!) use scsi_transfer_length in target context, it uses it in it's initiator side in the same way as iscsi, so the same semantics apply. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
