I've been looking over the BIDI code a bit thinking how it would make
use of multiple tasks per command.
Right now the only supported bidi commands are the two XDWRITEREAD
versions.
XDWRITEREAD is defined as:
1) read the specified logical block(s);
2) transfer logical blocks from the data-out buffer;
3) XOR the logical blocks transferred from the data-out buffer with the
logical blocks read, storing the resulting XOR data in a buffer;
4) if the DISABLE WRITE bit is set to zero, then write the logical
blocks transferred from the data-out buffer; and
5) transfer the resulting XOR data to the data-in buffer.
It seems like the code currently always handles an XDWRITEREAD comand
as if the DISABLE WRITE bit was always set, without actually checking
for it. This seems like fairly dangerous behaviour for users of the
command, as not setting DISABLE WRITE seems to be the only somewhat
sensible use of this command, if there is any at all.
Also even for that case I can't see how it would work at all - in
transport_generic_new_cmd we allocate at least one task for the write
and read side, but there seems to discrimination in handling the read
tasks that need to be scheduled now, and the write tasks that need to
be completely ignored with the current code, respectively scheduled
once the XOR has been completed if data writeback was implemented.
Does anyone know who is using this command for what, and why it matters
for the kernel scsi target, specially given the very limited number
of protocols and initiators that actually support bidi commands?
Do we have any test code verifying things actually work, or
alternatively proving my theory?
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
