On Wed, Dec 21, 2011 at 3:07 PM, Nicholas A. Bellinger
<nab@xxxxxxxxxxxxxxx> wrote:
> So that said, I'm thinking to silently succeed on allocate length zero,
After discussing this offline with a few people, I now realize we can't
just silently succeed, at least the way my previous patch for data
commands did. (ie that patch is wrong, although better than crashing)
The problem is that returning immediately like that bypasses the
sequencer, which means we incorrectly skip reservation checking,
returning unit attention, etc.
I think that having any special case for 0-length commands is
going to be really hard to get right and will duplicate all this logic,
so really it would be better to somehow separate out the data
movement phase and just succeed that without moving any data.
Any thoughts on a clean way to implement that?
> > And also I think the code that fails INQUIRY with allocation length < 6
> > is wrong too -- eg if the initiator sense us an allocation length of
> > 1, we should
> > return good status and just send back the first byte of the inquiry data.
> > But that's a secondary issue -- at least we don't crash in that case.
> I'm not sure if supporting this type of scenario makes sense, as I've
> never actually seen it in practice.
Really we should try to find a way to comply with the SCSI spec,
and ideally our data movement handling should just work for
arbitrary allocation lengths. I think we should be able to come up
with something that handles crazy stuff like an allocation length
of 1 for INQUIRY and also lets us get rid of ad hoc code like
/*
* 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;
}
(with code like that we'll always have more cases to take
care of and we'll always make mistakes, and in fact I think
this code is wrong since my reading of SPC is that the
additional length value shouldn't depend on the allocation
length from the initiator...)
- 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
