As I've mentioned before, we have a lot of fragile (and incorrect) code like
if (cmd->data_length < 6) {
pr_err("SCSI Inquiry payload length: %u"
" too small for EVPD=0\n", cmd->data_length);
return -EINVAL;
}
and
if (cmd->data_length < (0x10 + 4)) {
pr_debug("Received data_length: %u"
" too small for EVPD 0xb0\n",
cmd->data_length);
return -EINVAL;
}
if (have_tp && cmd->data_length < (0x3c + 4)) {
pr_debug("Received data_length: %u"
" too small for TPE=1 EVPD 0xb0\n",
cmd->data_length);
have_tp = 0;
}
that tries to handle allocation length for various INQUIRY commands.
What we really are supposed to do is act as if we generate the full
response, and then only return the data that the initiator asked for.
The cleanest way that I see to fix this is to make sure at the beginning
of target_emulate_inquiry() that we have a big enough buffer to handle
the full response, and then get rid of all these downstream checks.
For fabrics where the target core allocates the buffer, this is pretty
trivial -- we always have a full page, which is more than enough for
every INQUIRY response we have. The only complication is with
fabrics like loopback where we might be using a buffer allocated
by the SCSI midlayer, which is limited to the allocation length the
initiator actually sent.
So what would everyone think of just testing cmd flags against
SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC at the
start of target_emulate_inquiry(), and if it is set and data_length
is less than some minimum, just allocate an auxiliary buffer
and copying back to the real memory at the end of inquiry
emulation? It's not like inquiry is a performance path operation,
and we only take the overhead in a limited set of circumstances.
- 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
