> > On 07/02/2013 10:27, FUJITA Tomonori wrote: >> >> I've just started to look at the code. I agree that the current code >> to handle various lengths is messy. However, my question is what are >> actual problems that this patchset fixes? Tomo, Actually the motivation was two-fold. 1) For the first part let me refer you to the comment supplied for [PATCH 01/13]. It is quite long but it should tell the story. Actually Or Gerlitz has already quoted one passage from there : On Thu, Feb 7, 2013 at 11:31 AM, Or Gerlitz <ogerlitz@xxxxxxxxxxxx> wrote: > These patches solved a real world interoperability problem between TGT and > the ESX initiator, as Alex describes in the commit message of patch number > #1: > > "Current iser.c implementation behaves according to the spec, but because > the SCSI layer sometimes does not, it may occasionally produce incorrect > responses. Linux initiator disregards them, but more pedantic initiators, > like VmWare's ESX, throws errors. > > This patch basically forces SCSI layer to set only the actual transfer len > as described in section 2.5. and to implement residual+overflow > calculations as > described in section 3. of the above algorithm entirely in the Transport > layer." > I should have stressed it more in the main description piece. I would also quote another passage as important: "Currently, iscsid.c always truncates the case of READ overflow (resid < 0) and sets resid = 0. As explained above this is correct behavior with SPC cmds (no overflows), but overflows should not have been produced by SPC module in the first place, while with READ SBC commands overflow MUST be reported." 2) The second part is just fixing quite a few small "corner-case" bugs in SPC and SBC's SPC-like cmds, while trying to do it a more or less uniform manner: using the same names for variables, calling the same functions etc. Two parts actually modify the same pieces of code as the changes are interrelated. Alexander -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
