On Mon, Jan 9, 2012 at 5:32 PM, Andy Grover <agrover@xxxxxxxxxx> wrote:
>> But OTOH it would be good if we allocate the memory on demand
>> to handle the 2GB allocation length case I mentioned above, so we
>> handle the case where an initiator sends us an allocation length
>> much longer than we actually need.
> Yeah this seems tricky to do at runtime...
One (stupid) possibility is to just do two passes, one to figure out
how long the response is, and one to actually allocate the memory
and generate the response.
>> The flip side of that is that we also want to handle the case where
>> the initiator sends an allocation length shorter than what we need
>> to return the data. What we're supposed to do in that case is act
>> like we generated the whole response but truncate the actual data
>> we return.
>
> Looking at the code, this appears to be in place.
I don't think so... there are lots of bugs here, eg look at
target_emulate_inquiry_std(). It has lots of open-coded
checks of cmd->data_length. eg
if (cmd->data_length < 6) {
pr_err("SCSI Inquiry payload length: %u"
" too small for EVPD=0\n", cmd->data_length);
return -EINVAL;
}
is wrong, we're supposed to truncate not fail in this case.
Similarly
/*
* Do not include vendor, product, reversion info in INQUIRY
* response payload for cdbs with a small allocation length.
*/
if (cmd->data_length < 36) {
buf[4] = 3; /* Set additional length to 3 */
goto out;
}
is wrong, if data_length is 35, we should just return the
first 35 bytes of the inquiry response.
And target_emulate_evpd_83() looks like it must have
multiple buffer overruns in it, etc.
--
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
