| Message ID | 1c10437e3cd9be8556e77462b40ad53be542dfba.1468384890.git.tom.ty89@gmail.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
Hello, On Wed, Jul 13, 2016 at 12:47:06PM +0800, tom.ty89@gmail.com wrote: > From: Tom Yan <tom.ty89@gmail.com> > > ATA_MAX_SECTORS_LBA48 is only used for setting the queue limit > "max_hw_sectors", which only serves as the cap for "max_sectors", > which is in turn the actual limit being used. Therefore, it should It's used to device max_sectors. > be alright for us to bump ATA_MAX_SECTORS_LBA48 to 65536. Also, > lba_48_ok() has been accepting the number of blocks to be 65536. This is way too gratuitous. There's no rationale for it while it has actual real-world risks. max_sectors is staying at 65535. Thanks.
On 14 July 2016 at 01:03, Tejun Heo <tj@kernel.org> wrote: > > It's used to device max_sectors. > Not really. "max_sectors" of ATA drives have been set to BLK_DEF_MAX_SECTORS, for at least quite some time. > > This is way too gratuitous. There's no rationale for it while it has > actual real-world risks. max_sectors is staying at 65535. > That's alright. I don't have strong opinion on whether we should bump this anyway. So I suppose we should replace the TODO comment with something like "avoid count to be 0000h"? And maybe also change ATA_MAX_SECTORS to 255 (with comment "avoid count to be 00h")? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 15, 2016 at 02:22:52AM +0800, Tom Yan wrote: > On 14 July 2016 at 01:03, Tejun Heo <tj@kernel.org> wrote: > > > > It's used to device max_sectors. > > > > Not really. "max_sectors" of ATA drives have been set to > BLK_DEF_MAX_SECTORS, for at least quite some time. > > > > > This is way too gratuitous. There's no rationale for it while it has > > actual real-world risks. max_sectors is staying at 65535. > > > > That's alright. I don't have strong opinion on whether we should bump > this anyway. So I suppose we should replace the TODO comment with > something like "avoid count to be 0000h"? And maybe also change > ATA_MAX_SECTORS to 255 (with comment "avoid count to be 00h")? I'd just leave both alone. It's one sector difference one way or the other and those numbers have a pretty long history. There's no reason to disturb them at this point. There's no actual gain whatsoever but there is some actual risk. Thanks.
diff --git a/include/linux/ata.h b/include/linux/ata.h index 99346be..24f886c 100644 --- a/include/linux/ata.h +++ b/include/linux/ata.h @@ -46,7 +46,7 @@ enum { ATA_MAX_SECTORS_128 = 128, ATA_MAX_SECTORS = 256, ATA_MAX_SECTORS_1024 = 1024, - ATA_MAX_SECTORS_LBA48 = 65535,/* TODO: 65536? */ + ATA_MAX_SECTORS_LBA48 = 65536, ATA_MAX_SECTORS_TAPE = 65535, ATA_ID_WORDS = 256,