Re: [PATCH v2 1/3] scsi_cmnd: Introduce scsi_transfer_length helper

[Christoph Hellwig <hch@infradead.org>]

> >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.