On 08/25/2014 12:27 PM, Wyllys Ingersoll wrote: > in iscsi_copy_operational_params, the conn->max_recv_dlength is set to > _padding (conn_conf->MaxRecvDataSegmentLength); > > initiator_common.c:153 :: conn->max_recv_dlength = > __padding(conn_conf->MaxRecvDataSegmentLength); > > This (_padding) rounds up the value. If the configured > MaxRecvDataSegmentLength is set to the actual maximum (2^24 -1 : > 16777215), the _padding function changes it to 16777216, causing the > comparison to fail since it is above the maximum and it resets the > value to the default minimum (262144). This is probably not the > intended result. > > The actual maximum is really 16777212 since 16777212 & 0x03 == 0, > which will cause it to pass thru the _padding function with no change. >
Nice catch. Yeah, it is a bug in the iscsi code as far as I can tell. I should be able to send a patch shortly. Just curious, did you have a need for a Length this large, or were you just testing? > The _padding issue probably affects other parameters as well, thats > the one where I first noticed the problem. > It does. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
