linux-kernel - Re: [PATCH] ata: Add support for Long Logical Sectors and Long Physical Sectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Aug 2008 10:06:47 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matthew Wilcox <matthew@....cx>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	jgarzik@...ox.com, Matt_Domsch@...l.com,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: Re: [PATCH] ata: Add support for Long Logical Sectors and Long
 Physical Sectors

On Tue, 5 Aug 2008 20:22:55 -0600
Matthew Wilcox <matthew@....cx> wrote:

> On Tue, Aug 05, 2008 at 09:46:51PM +0100, Alan Cox wrote:
> > > + * Some commands are specified to transfer (a multiple of) 512 bytes of data
> > > + * while others transfer a multiple of the number of bytes in a sector.  This
> > > + * function knows which commands transfer how much data.
> > 
> > 	static u32 ata_sector_or_block[]={...};
> > 
> > 	if (test_bit(tf->cmd, &ata_sector_or_block))
> > 
> > looks so much more elegant than a giant switch statement and I suspect
> > produces far better code
> 
> Probably ... I did consider it, but I think I was too influenced by the
> existing READ/WRITE LONG code.
> 
> > > + * ATA supports sector sizes up to 2^33 - 1.  The reported sector size may
> > > + * not be a power of two.  The extra bytes are used for user-visible data
> > > + * integrity calculations.  Note this is not the same as the ECC which is
> > > + * accessed through the SCT Command Transport or READ / WRITE LONG.
> > > + */
> > > +static u64 ata_id_sect_size(const u16 *id)
> > 
> > word 106 is not defined in early ATA standards so it would be wise to
> > check that ATA8 is reported by the drive - and trust the relevant bits
> > for ATA7/8 as appropriate.
> 
> I'm not sure that's necessary.  The spec says to check whether words are
> valid by doing the & 0xc000 == 0x4000 test.

What early spec says what state word 106 is in ? Healthy paranoia is a
good idea in the IDE world because its all a bit murky in the early days
and you get some quite strange ident data from early devices - one reason
for 0xC000 = 0x4000 is that some early drives use 0xFFFF for unknown words
for example!

> good migration path?  We could have the driver set a flag, or call into
> the driver from the midlayer to check whether it can cope with a
> particular sector size.

On the driver side I need to know so I can control the FIFO so I guess
knowing when you start/end planning to use large sector sizes. The driver
could do it per command but the cost is almost certainly not worth it as
I'd expect us to stick to a size. A driver method would do the trick
nicely if it could return -EOPNOTSUPP or similar.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/