On Mon, Nov 26 2007 at 17:35 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > Not all devices correctly report the error-causing LBA in the > Information field of their sense data -- even when they set the Valid > bit. This patch (as1019) makes sd much more cautious about accepting > the reported LBA. If the value isn't within the range of blocks > accessed during the I/O operation it is rejected, and instead the > driver will try looking at the residue field (which currently it > ignores completely). > > This fixes a data-corruption bug reported here: > > http://marc.info/?t=118745764700005&r=1&w=2 > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > CC: Luben Tuikov <ltuikov@xxxxxxxxx> > > --- > > This patch should be considered for inclusion in 2.6.24. The bug in > question has always existed, as far as I know, but before 2.6.18 it was > masked by a different bug. > > This doesn't use the new SCSI accessors. In the development trees > I've seen, those accessors haven't yet been imported into sd.c. If > the patch needs to be rebased, please let me know where to find the > current sd source. > It's currently only in mm patchset has: bidi-support-sr-sd-remove-dead-code.patch && bidi-support-scsi_data_buffer.patch > Presumably sr should use the same algorithm. That's grist for another > patch. > > > Index: usb-2.6/drivers/scsi/sd.c > =================================================================== > --- usb-2.6.orig/drivers/scsi/sd.c > +++ usb-2.6/drivers/scsi/sd.c > @@ -968,7 +968,17 @@ static int sd_done(struct scsi_cmnd *SCp <snip> If this is a bugfix for 2.6.24 than I will be the one to rebase, as scsi_data_buffer is only for 2.6.25, I hope ;) Andrew once above goes into scsi-rc-fixes or scsi-misc I will send a rebase, if I've fallen asleep please bang me on the head, thanks. Alen thanks for doing this It was on my must-investigate list. (Though I'm usually not using sd) Boaz - 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
