[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