Message ID | 1494197759.30469.39.camel@haakon3.risingtidesystems.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Sun, 2017-05-07 at 15:55 -0700, Nicholas A. Bellinger wrote: > diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c > index a0ad618..2cc8753 100644 > --- a/drivers/target/target_core_sbc.c > +++ b/drivers/target/target_core_sbc.c > @@ -836,10 +836,8 @@ static sense_reason_t compare_and_write_callback(struct se_cmd *cmd, bool succes > * @cmd: (in) structure that describes the SCSI command to be parsed. > * @sectors: (out) Number of logical blocks on the storage medium that will be > * affected by the SCSI command. > - * @bufflen: (out) Expected length of the SCSI Data-Out buffer. > */ > -static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > - u32 *bufflen) > +static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, unsigned int *sectors) > { > struct se_device *dev = cmd->se_dev; > u8 *cdb = cmd->t_task_cdb; > @@ -871,10 +869,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > > switch (bytchk) { > case 0: > - *bufflen = 0; > - break; > case 1: > - *bufflen = sbc_get_size(cmd, *sectors); > cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB; > break; > default: > @@ -967,7 +962,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > break; > case WRITE_VERIFY: > case WRITE_VERIFY_16: > - ret = sbc_parse_verify(cmd, §ors, &size); > + ret = sbc_parse_verify(cmd, §ors); > if (ret) > return ret; > cmd->execute_cmd = sbc_execute_rw; > @@ -1169,7 +1164,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > break; > case VERIFY: > case VERIFY_16: > - ret = sbc_parse_verify(cmd, §ors, &size); > + ret = sbc_parse_verify(cmd, §ors); > if (ret) > return ret; > cmd->execute_cmd = sbc_emulate_noop; As I have already explained in another e-mail: the above change is completely wrong. Bart.-- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2017-05-08 at 18:10 +0000, Bart Van Assche wrote: > On Sun, 2017-05-07 at 15:55 -0700, Nicholas A. Bellinger wrote: > > diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c > > index a0ad618..2cc8753 100644 > > --- a/drivers/target/target_core_sbc.c > > +++ b/drivers/target/target_core_sbc.c > > @@ -836,10 +836,8 @@ static sense_reason_t compare_and_write_callback(struct se_cmd *cmd, bool succes > > * @cmd: (in) structure that describes the SCSI command to be parsed. > > * @sectors: (out) Number of logical blocks on the storage medium that will be > > * affected by the SCSI command. > > - * @bufflen: (out) Expected length of the SCSI Data-Out buffer. > > */ > > -static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > > - u32 *bufflen) > > +static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, unsigned int *sectors) > > { > > struct se_device *dev = cmd->se_dev; > > u8 *cdb = cmd->t_task_cdb; > > @@ -871,10 +869,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > > > > switch (bytchk) { > > case 0: > > - *bufflen = 0; > > - break; > > case 1: > > - *bufflen = sbc_get_size(cmd, *sectors); > > cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB; > > break; > > default: > > @@ -967,7 +962,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > > break; > > case WRITE_VERIFY: > > case WRITE_VERIFY_16: > > - ret = sbc_parse_verify(cmd, §ors, &size); > > + ret = sbc_parse_verify(cmd, §ors); > > if (ret) > > return ret; > > cmd->execute_cmd = sbc_execute_rw; > > @@ -1169,7 +1164,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, > > break; > > case VERIFY: > > case VERIFY_16: > > - ret = sbc_parse_verify(cmd, §ors, &size); > > + ret = sbc_parse_verify(cmd, §ors); > > if (ret) > > return ret; > > cmd->execute_cmd = sbc_emulate_noop; > > As I have already explained in another e-mail: the above change is completely wrong. Nope. If your original patch had been run through libiscsi before posting it, you'd have already caught the regression. So run it though libiscsi and see for yourself that it restores existing behavior. In any event, this is the patch I'll be merging for -rc1 to restore existing behavior to avoid the OOPsen your change has introduced. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2017-05-09 at 21:32 -0700, Nicholas A. Bellinger wrote: > On Mon, 2017-05-08 at 18:10 +0000, Bart Van Assche wrote: > > [ ... ] > > As I have already explained in another e-mail: the above change is completely wrong. > > In any event, this is the patch I'll be merging for -rc1 to restore > existing behavior to avoid the OOPsen your change has introduced. Hello Nic, In case it wouldn't be clear, my reply counts as a NAK. Please add the following to that patch before you send it to Linus: NAK-ed-by: Bart Van Assche <Bart.VanAssche@sandisk.com> Thanks, Bart.-- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2017-05-10 at 16:12 +0000, Bart Van Assche wrote: > On Tue, 2017-05-09 at 21:32 -0700, Nicholas A. Bellinger wrote: > > On Mon, 2017-05-08 at 18:10 +0000, Bart Van Assche wrote: > > > [ ... ] > > > As I have already explained in another e-mail: the above change is completely wrong. > > > > In any event, this is the patch I'll be merging for -rc1 to restore > > existing behavior to avoid the OOPsen your change has introduced. > > Hello Nic, > > In case it wouldn't be clear, my reply counts as a NAK. Please add the > following to that patch before you send it to Linus: > > NAK-ed-by: Bart Van Assche <Bart.VanAssche@sandisk.com> > Listen, your patch in target-pending/for-next broke existing behavior for WRITE_VERIFY because you never bothered to test the original patch with overflow, so I'm going to include this bug-fix in my PULL request so it doesn't trigger an OOPs. Otherwise I'll just revert your original patch and be done with it for -rc1. Which do you prefer..? -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c index a0ad618..2cc8753 100644 --- a/drivers/target/target_core_sbc.c +++ b/drivers/target/target_core_sbc.c @@ -836,10 +836,8 @@ static sense_reason_t compare_and_write_callback(struct se_cmd *cmd, bool succes * @cmd: (in) structure that describes the SCSI command to be parsed. * @sectors: (out) Number of logical blocks on the storage medium that will be * affected by the SCSI command. - * @bufflen: (out) Expected length of the SCSI Data-Out buffer. */ -static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, - u32 *bufflen) +static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, unsigned int *sectors) { struct se_device *dev = cmd->se_dev; u8 *cdb = cmd->t_task_cdb; @@ -871,10 +869,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, switch (bytchk) { case 0: - *bufflen = 0; - break; case 1: - *bufflen = sbc_get_size(cmd, *sectors); cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB; break; default: @@ -967,7 +962,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, break; case WRITE_VERIFY: case WRITE_VERIFY_16: - ret = sbc_parse_verify(cmd, §ors, &size); + ret = sbc_parse_verify(cmd, §ors); if (ret) return ret; cmd->execute_cmd = sbc_execute_rw; @@ -1169,7 +1164,7 @@ static sense_reason_t sbc_parse_verify(struct se_cmd *cmd, int *sectors, break; case VERIFY: case VERIFY_16: - ret = sbc_parse_verify(cmd, §ors, &size); + ret = sbc_parse_verify(cmd, §ors); if (ret) return ret; cmd->execute_cmd = sbc_emulate_noop;