diff mbox

[RFC,1/3] ata: bump ATA_MAX_SECTORS_LBA48 to 65536

Message ID 1c10437e3cd9be8556e77462b40ad53be542dfba.1468384890.git.tom.ty89@gmail.com
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Tom Yan July 13, 2016, 4:47 a.m. UTC
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
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.

Signed-off-by: Tom Yan <tom.ty89@gmail.com>

Comments

Tejun Heo July 13, 2016, 5:03 p.m. UTC | #1
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.
Tom Yan July 14, 2016, 6:22 p.m. UTC | #2
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-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo July 14, 2016, 6:26 p.m. UTC | #3
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 mbox

Patch

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,