| Message ID | Pine.LNX.4.44L0.1701301055100.2025-100000@iolanthe.rowland.org (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
On Monday 30 January 2017 17:17:03 Alan Stern wrote: > On Sun, 29 Jan 2017, Pali Rohár wrote: > > On Wednesday 11 January 2017 16:23:29 Alan Stern wrote: > > > On Tue, 10 Jan 2017, James Bottomley wrote: > > > > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote: > > > > > In theory, I suppose we could change the kernel so that it > > > > > would default to READ CAPACITY(16) for devices that report a > > > > > SCSI level > > > > > > > > > > >= 3, or something along those lines. In general we hesitate > > > > > >to > > > > > > > > > > make changes of this sort, because they almost always end up > > > > > breaking _some_ devices -- and if that happens then the > > > > > change is reverted, with no exceptions. Linus has a very > > > > > strict rule about not breaking working systems. > > > > > > > > You shouldn't have to change anything: it already does > > > > (otherwise how else would we detect physical exponent for > > > > proper SCSI devices) see sd.c:sd_try_rc16_first(). It always > > > > returns false for USB because you set sdev->try_rc_10_first > > > > > > In fact, this approach probably won't work. See Bugzilla entries > > > #43265 and #43391. The devices in those reports claimed to be > > > ANSI level 4, but they failed anyway. > > > > Seems those devices return capacity 0x7F000000000001 or > > 0xFF000000000001 Maybe there is some error pattern? > > As far as I can tell, they both reported 0xFF000000000001. That's a > pattern -- unless somebody really does have a storage device that > large (18 exabytes). For the time being, perhaps we can ignore this > possibility. > > > > If you guys want to try the quirk flag, you can apply the patch > > > below. Then set the usb-storage module parameter > > > quirks=vvvv:pppp:k where vvvv and pppp are the Vendor and > > > Product ID codes for your device (as 4 hex digits). > > > > > > In the long run, however, this is not a viable approach. We'd be > > > better off with an explicit blacklist. > > > > Ok, so what are next steps? I think that explicit blacklist would > > be needed if "bad" devices is less. > > > > How many bug reports were there? > > I don't know. > > Anyway, please try out the patch below. I don't know if it will be > acceptable to the SCSI maintainers, but we should at least make sure > it fixes your problem before submitting it. I'm not original reporter of this problem. Dainius, can you test it? > Alan Stern > > > > > Index: usb-4.x/drivers/scsi/sd.c > =================================================================== > --- usb-4.x.orig/drivers/scsi/sd.c > +++ usb-4.x/drivers/scsi/sd.c > @@ -2157,6 +2157,13 @@ static int read_capacity_16(struct scsi_ > return -ENODEV; > } > > + /* Some buggy devices report an impossibly large size */ > + if (lba >= (1ULL << 54)) { > + sd_printk(KERN_WARNING, sdkp, "Read Capacity(16) returned > excessively large value: %llu", lba); + sdkp->capacity = 0; > + return -EINVAL; > + } > + > if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xffffffffULL)) { > sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a " > "kernel compiled with support for large block " > Index: usb-4.x/drivers/usb/storage/scsiglue.c > =================================================================== > --- usb-4.x.orig/drivers/usb/storage/scsiglue.c > +++ usb-4.x/drivers/usb/storage/scsiglue.c > @@ -247,8 +247,11 @@ static int slave_configure(struct scsi_d > * Tell the SCSI layer to try READ_CAPACITY_10 first. > * However some USB 3.0 drive enclosures return capacity > * modulo 2TB. Those must use READ_CAPACITY_16 > + * > + * Assume SPC3 or later devices can handle READ_CAPACITY_16. > */ > - if (!(us->fflags & US_FL_NEEDS_CAP16)) > + if (sdev->scsi_level <= SCSI_SPC_2 && > + !(us->fflags & US_FL_NEEDS_CAP16)) > sdev->try_rc_10_first = 1; > > /* assume SPC3 or latter devices support sense size > 18 */
On Monday 30 January 2017 18:43:12 Pali Rohár wrote: > On Monday 30 January 2017 17:17:03 Alan Stern wrote: > > On Sun, 29 Jan 2017, Pali Rohár wrote: > > > On Wednesday 11 January 2017 16:23:29 Alan Stern wrote: > > > > On Tue, 10 Jan 2017, James Bottomley wrote: > > > > > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote: > > > > > > In theory, I suppose we could change the kernel so that it > > > > > > would default to READ CAPACITY(16) for devices that report a > > > > > > SCSI level > > > > > > > > > > > > >= 3, or something along those lines. In general we hesitate > > > > > > >to > > > > > > > > > > > > make changes of this sort, because they almost always end up > > > > > > breaking _some_ devices -- and if that happens then the > > > > > > change is reverted, with no exceptions. Linus has a very > > > > > > strict rule about not breaking working systems. > > > > > > > > > > You shouldn't have to change anything: it already does > > > > > (otherwise how else would we detect physical exponent for > > > > > proper SCSI devices) see sd.c:sd_try_rc16_first(). It always > > > > > returns false for USB because you set sdev->try_rc_10_first > > > > > > > > In fact, this approach probably won't work. See Bugzilla entries > > > > #43265 and #43391. The devices in those reports claimed to be > > > > ANSI level 4, but they failed anyway. > > > > > > Seems those devices return capacity 0x7F000000000001 or > > > 0xFF000000000001 Maybe there is some error pattern? > > > > As far as I can tell, they both reported 0xFF000000000001. That's a > > pattern -- unless somebody really does have a storage device that > > large (18 exabytes). For the time being, perhaps we can ignore this > > possibility. > > > > > > If you guys want to try the quirk flag, you can apply the patch > > > > below. Then set the usb-storage module parameter > > > > quirks=vvvv:pppp:k where vvvv and pppp are the Vendor and > > > > Product ID codes for your device (as 4 hex digits). > > > > > > > > In the long run, however, this is not a viable approach. We'd be > > > > better off with an explicit blacklist. > > > > > > Ok, so what are next steps? I think that explicit blacklist would > > > be needed if "bad" devices is less. > > > > > > How many bug reports were there? > > > > I don't know. > > > > Anyway, please try out the patch below. I don't know if it will be > > acceptable to the SCSI maintainers, but we should at least make sure > > it fixes your problem before submitting it. > > I'm not original reporter of this problem. > > Dainius, can you test it? Just want to remind this patch so it will not be forgotten... > > Alan Stern > > > > > > > > > > Index: usb-4.x/drivers/scsi/sd.c > > =================================================================== > > --- usb-4.x.orig/drivers/scsi/sd.c > > +++ usb-4.x/drivers/scsi/sd.c > > @@ -2157,6 +2157,13 @@ static int read_capacity_16(struct scsi_ > > return -ENODEV; > > } > > > > + /* Some buggy devices report an impossibly large size */ > > + if (lba >= (1ULL << 54)) { > > + sd_printk(KERN_WARNING, sdkp, "Read Capacity(16) returned excessively large value: %llu", lba); > > + sdkp->capacity = 0; > > + return -EINVAL; > > + } > > + > > if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xffffffffULL)) { > > sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a " > > "kernel compiled with support for large block " > > Index: usb-4.x/drivers/usb/storage/scsiglue.c > > =================================================================== > > --- usb-4.x.orig/drivers/usb/storage/scsiglue.c > > +++ usb-4.x/drivers/usb/storage/scsiglue.c > > @@ -247,8 +247,11 @@ static int slave_configure(struct scsi_d > > * Tell the SCSI layer to try READ_CAPACITY_10 first. > > * However some USB 3.0 drive enclosures return capacity > > * modulo 2TB. Those must use READ_CAPACITY_16 > > + * > > + * Assume SPC3 or later devices can handle READ_CAPACITY_16. > > */ > > - if (!(us->fflags & US_FL_NEEDS_CAP16)) > > + if (sdev->scsi_level <= SCSI_SPC_2 && > > + !(us->fflags & US_FL_NEEDS_CAP16)) > > sdev->try_rc_10_first = 1; > > > > /* assume SPC3 or latter devices support sense size > 18 */ >
Index: usb-4.x/drivers/scsi/sd.c =================================================================== --- usb-4.x.orig/drivers/scsi/sd.c +++ usb-4.x/drivers/scsi/sd.c @@ -2157,6 +2157,13 @@ static int read_capacity_16(struct scsi_ return -ENODEV; } + /* Some buggy devices report an impossibly large size */ + if (lba >= (1ULL << 54)) { + sd_printk(KERN_WARNING, sdkp, "Read Capacity(16) returned excessively large value: %llu", lba); + sdkp->capacity = 0; + return -EINVAL; + } + if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xffffffffULL)) { sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a " "kernel compiled with support for large block " Index: usb-4.x/drivers/usb/storage/scsiglue.c =================================================================== --- usb-4.x.orig/drivers/usb/storage/scsiglue.c +++ usb-4.x/drivers/usb/storage/scsiglue.c @@ -247,8 +247,11 @@ static int slave_configure(struct scsi_d * Tell the SCSI layer to try READ_CAPACITY_10 first. * However some USB 3.0 drive enclosures return capacity * modulo 2TB. Those must use READ_CAPACITY_16 + * + * Assume SPC3 or later devices can handle READ_CAPACITY_16. */ - if (!(us->fflags & US_FL_NEEDS_CAP16)) + if (sdev->scsi_level <= SCSI_SPC_2 && + !(us->fflags & US_FL_NEEDS_CAP16)) sdev->try_rc_10_first = 1; /* assume SPC3 or latter devices support sense size > 18 */