On 01/21/2012 12:20 AM, Roland Dreier wrote:
> 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.
>
What I did for my megasas emulation was to allocate the temp buffer
on the stack. What with this being an emulation I pretty much know
how large that has to be.
And then copy it back into the space provided.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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
