RE: Request for review of Linux iSCSI driver version 4.0.0.1

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Mon, 1 Dec 2003, Andre Hedrick wrote:

> If a "memcpy" is held and the original content changes with the top level
> caller not marking the request dirty, BOOM you just commited crap to
> platter.

This is irrelevant for this discussion, it's the responsibility of the
caller to ensure data integrity, when it's modifying the data while it's
written. The iSCSI driver is only responsible for the checksum generation.

> If you are not zero-copy to the network stack, you will never catch the
> changes between calculation of the CRC32C and pumping to the wire.
>
> iSCSI(MC)
>
> BLOCK->SCSI->iSCSI->MEMCPY->CRC32C->TCP->WIRE
>                               ^^^^^^^^^^^^^^
>                               BOOM memory buffers change

If the driver uses a private buffer, there is nobody who can change it
(otherwise it's simply a bug).

> iSCSI(MC) passes CRC32C
>
> iSCSI(ZC) fails CRC32C, and retries the failed PDU.
>
> It should be clear that any TARGET, INITIATOR, or PAIR doing iSCSI(MC)
> will roast your data.
>
> Now iSCSI(ZC) requires ERL >= 1 w/ Sync-and-Steering.

Wrong, the iSCSI standard allows to escalate the error handling to the
SCSI layer. It's a different problem whether our SCSI layer can deal with
it or not.
There are multiple valid ways to recover from a digest error, there is not
just one true way as you suggest.

> Real iSCSI does ERL >= 2, but then again > 2 means new async-connections.

ERL0 is also "real iSCSI".

bye, Roman