On Mon, 10 Mar 2008, Boaz Harrosh wrote: > > No need, the problem you're thinking of in sd has been fixed. The > > problem was that sd did not check the value of error_sector to make > > sure it was within the range of sectors accessed by the command. I'm > > not sure if an equivalent fix has been applied to sr, however. > > I certainly remember a very nice patch sent following the one to sd. > That revamps the all sr error handling path, including above problem. > I'm not sure it was submitted upstream though. I don't think it was. The MEDIUM_ERROR case in sr_done() is still a mess. That function doesn't even use the new sense-buffer accessor routines. Something else to add to your TODO list? > OK, I see what you are saying: In case of bad behaving device, that we do > not know about. The residue can be an indication of an actual error that should > not be ignored. Sound's reasonable. In my opinion only a ULD like sd/sr could > really know such things for sure. (Given the knowledge of command submitted) > So a fix should go there. Both your patch and Jame's, touch code that does not > have enough information to be sure. At the moment sd and sr are the only ULDs which support block access FS commands, so it doesn't make much difference. However I disagree that only a ULD could know for sure whether a positive residue in a FS command indicates an error. IMO, a residue in any FS command should always be taken seriously. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
