On Wed, 2011-03-23 at 07:06 -0700, Luben Tuikov wrote: > --- On Mon, 3/21/11, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > Subject: [PATCH] sd: Fix regression in sd_read_cache_type > > To: "James Bottomley" <James.Bottomley@xxxxxxx> > > Cc: "Richard Senior" <richard@xxxxxxxxxxxxxxxxxxxx>, "Luben Tuikov" <ltuikov@xxxxxxxxx>, "SCSI development list" <linux-scsi@xxxxxxxxxxxxxxx> > > Date: Monday, March 21, 2011, 2:29 PM > > This patch (as1454) fixes a > > regression in the sd driver. Commit > > 24d720b726c1a85f1962831ac30ad4d2ef8276b1 ([SCSI] Retrieve > > the Caching > > mode page) recently introduced the strategy of asking for > > all pages > > (page code 0x3F) instead of asking for the caching page > > (0x08) on > > devices that might not support it. This ought to be > > safe, because sd > > already uses page code 0x3F when checking for write > > protection. > > > > Unfortunately, the commit did not copy the checks used by > > sd_read_write_protect_flag(). Some devices don't > > support page code > > 0x3F, and others require a fixed transfer length of 192 > > bytes. This > > patch adds those checks into sd_read_cache_type(). > > > > Without this fix, some USB mass-storage devices crash when > > they > > receive a MODE SENSE command with page code 0x3F asking for > > only 4 > > bytes of data. > > > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > Reported-and-tested-by: Richard Senior <richard@xxxxxxxxxxxxxxxxxxxx> > > CC: Luben Tuikov <ltuikov@xxxxxxxxx> > > CC: <stable@xxxxxxxxxx> > > Acked-by: Luben Tuikov <ltuikov@xxxxxxxxx> I put the original patch in on the understanding from both of you that the chances of finding a USB device which crashed with the change was very small. Given that several have been found and we're on the eve of the merge window closure, I'll just revert the original, and you two can work on getting a bullet proof version for the next merge window. James -- 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
