[illumos-Developer] review for 653: https://www.illumos.org/issues/653
Garrett D'Amore
garrett at nexenta.com
Fri Jan 21 11:35:47 PST 2011
I've added the following paragraph to the comment:
* Note that we assume that the new PDU is just a duplicate of
* the original. If the initiator is incorrectly sending other
* PDUs with the same cmdsn, then the behavior is undetermined,
* and the initiator deserves whatever it gets.
Hopefully that clears it up a bit.
- Garrett
On Fri, 2011-01-21 at 10:41 -0800, Eric Schrock wrote:
> On Fri, Jan 21, 2011 at 10:35 AM, Garrett D'Amore
> <garrett at nexenta.com> wrote:
>
>
> The second PDU *should* be a copy of the first, so I think it
> shouldn't
> matter which one we keep. Unless the Initiator is totally
> busted and
> incorrectly using cmdsns.
>
> I think there is a situation where the Initiator isn't broken,
> but may
> have sent a duplicate PDU due to lack of response/timeout.
> Admittedly
> I'm not an expert on this part of the protocol, so my
> understanding may
> be flawed.
>
> > I assume that there's no way to test this other than writing
> a custom
> > broken initiator (likely overkill for such a simple fix)?
>
>
> I am not aware of any other way to test it. This was just
> something I
> noticed by code inspection, not something we've actually seen
> in the
> field.
>
>
> Seems reasonable to me. One could imagine validating the contents of
> the new PDU match the old one, but that seems overkill for a "should
> never happen" case. Perhaps the comment should read "The contents of
> the PDU are assumed to be the same, so ...". Otherwise looks good.
>
>
> Thanks,
>
>
> - Eric
>
> --
> Eric Schrock, Delphix
>
More information about the Developer
mailing list