On Thu, Aug 16, 2012 at 3:12 PM, Nicholas A. Bellinger
<nab@xxxxxxxxxxxxxxx> wrote:
> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index 0eaae23..63b3594 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -1183,15 +1183,20 @@ int target_cmd_size_check(struct se_cmd *cmd, unsigned int size)
> /* Returns CHECK_CONDITION + INVALID_CDB_FIELD */
> goto out_invalid_cdb_field;
> }
> -
> + /*
> + * For the overflow case keep the existing fabric provided
> + * ->data_length. Otherwise for the underflow case, reset
> + * ->data_length to the smaller SCSI expected data transfer
> + * length.
> + */
> if (size > cmd->data_length) {
> cmd->se_cmd_flags |= SCF_OVERFLOW_BIT;
> cmd->residual_count = (size - cmd->data_length);
> } else {
> cmd->se_cmd_flags |= SCF_UNDERFLOW_BIT;
> cmd->residual_count = (cmd->data_length - size);
> + cmd->data_length = size;
> }
> - cmd->data_length = size;
> }
>
> return 0;
I don't think this can work... if my memory of the code is right, if we do this,
then the target core will only allocate the smaller (fabric) data length worth
of buffer space, but then it will actually execute whatever the CDB says to
do. So in my original example we're probably OK because we'll allocate a
full page anyway, but I think something like:
# sg_raw -r512 /dev/sda 28 0 0 0 0 0 0 0 9 0
would cause the target core to allocate 1 page but then read 9 sectors.
- R.
--
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
