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:	Tue, 5 Aug 2008 21:46:51 +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

> + * 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

> + * 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.

The drivers also need to know when a command is being issued which is a
funny shape as some hardware cannot do it because the internal state
machine knows the sector size and other stuff seems to need the internal
FIFO turning off or other things whacked repeatedly on the head to make
it work.

You also don't need to bother listing all the commands that don't have
data transfer phases as a sector size is meaningless there so we
shouldn't even bother doing a lookup for them. Indeed the more I look at
this the more it seems that keeping long complex ever out of date arrays
is the wrong way to do it.

We will also need a driver flag to indicate support in that HBA but that
is pretty trivial to add

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/