> Correct, so if the app client sets an allocation length > of 3, then at your discretion, you can either leave the > code doing what it does now, or return those 3 bytes. > IOW leave it alone, improve it but don't make it worse.
Ack, got the new spec and looks like the check < 4 is the correct one as we cannot fulfill the command in less than ten '4.2.5.6 Allocation length If the amount of information that is available to be transferred exceeds the maximum value that the ALLOCATION LENGTH field in combination with other fields in the CDB is capable of specifying, then no data shall be transferred and the command shall be terminated with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB. ' The only special case that needs to be taken care of is check for == 0 which is not an error... just do not return anything? > > I was noting that the boundary specified by the allocation > length (e.g. 3 or 11) may be an awkward fit for the loop > logic. For example you can't unconditionally use > put_unaligned_be32() into the response buffer if it was > kmalloc-ed for an allocation length of 3 bytes. That would not happen as we got out on < 4 and we use those 4 bytes to write the LUN LIST LENGTH Strangely the original code also ignored the allocation length from the request command and dumped whatever is available up to SDEBUG_RLUN_ARR_SZ That can be fixed too tough there some vague sentence: 'The contents of the LUN LIST LENGTH field are not altered based on the allocation length (see 4.2.5.6).' Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
