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-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikSSmP5f1csa=xPTR=EqY4D5a=6t2oDVkZ7cA-v@mail.gmail.com>
Date:	Sat, 14 Aug 2010 17:00:59 -0700
From:	Grant Grundler <grundler@...gle.com>
To:	Jeff Garzik <jgarzik@...ox.com>, Tejun Heo <tj@...nel.org>
Cc:	Linux IDE <linux-ide@...r.kernel.org>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	Gwendal Grignou <gwendal@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: [PATCH] 2.6.35 libata support for > 512 byte sectors (e.g. 4K Native)

Attached patch enables my x86 machine to recognize and talk to a
"Native 4K" SATA device.

When I started working on this, I didn't know Matthew Wilcox had
posted a similar patch 2 years ago:
   http://git.kernel.org/?p=linux/kernel/git/willy/ata.git;a=shortlog;h=refs/heads/ata-large-sectors

Gwendal Grignou pointed me at the the above code and small portions of
this patch include Matthew's work. That's why Mathew is first on the
"Signed-off-by:". I've NOT included his use of a bitmap to determine
512 vs Native for ATA command block size - just used a simple table.
And bugs are almost certainly mine.

Lastly, the patch has been tested with a native 4K 'Engineering
Sample' drive provided by Hitachi GST.

Signed-off-by: Matthew Wilcox <matthew.r.wilcox@...el.com>
Signed-off-by: Grant Grundler <grundler@...gle.com>
Reviewed-by: Gwendal Grignou <gwendal@...gle.com>

-----

Gwendal's review of this patch had him concerned about access to
"dev->sdev->sector_size" may have risks (e.g. sdev goes away before
dev does).  I didn't like adding additional fields to ata_dev that
duplicate what scsi is doing and this seems to be working so far. But
since I don't know how dev->sdev is protected/syncronized (despite how
libata and scsi are joined at the hip), I hope someone else can
comment on if my usage of dev->sdev->sector_size is a problem and why.

I believe use of ata_id_logical_per_physical_sectors() was wrong. I've
replaced it with ata_id_log2_per_physical_sector() and cleaned up how
block size word and alignment are referenced. It's alot easier to read
where those functions are used now.


Here is the kernel output from hotplugging the SATA drive on my
machine (using Marvell 7042 controller):

[ 2468.301218] ata4: exception Emask 0x10 SAct 0x0 SErr 0x4010000
action 0xe frozen
[ 2468.301225] ata4: edma_err_cause=00000010 pp_flags=00000000, dev connect
[ 2468.301240] ata4: SError: { PHYRdyChg DevExch }
[ 2468.301257] ata4: hard resetting link
[ 2471.701117] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2471.740390] ata4.00: HPA detected: current 9770670, native 78165360
[ 2471.740399] ata4.00: ATA-7: Hitachi HTSxxxxxxxxxxxx, yyyyyyyy, max UDMA/100
[ 2471.740402] ata4.00: 9770670 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 2471.764465] ata4.00: configured for UDMA/100
[ 2471.764501] ata4: EH complete
[ 2471.764988] scsi 4:0:0:0: Direct-Access     ATA      Hitachi
HTSxxxxxxxxxxxx PQ: 0 ANSI: 5
[ 2471.782914] sd 4:0:0:0: [sdd] 9770670 4096-byte logical blocks:
(40.0 GB/37.2 GiB)
[ 2471.787093] sd 4:0:0:0: [sdd] Write Protect is off
[ 2471.787120] sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[ 2471.788768] sd 4:0:0:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 2471.792293] sd 4:0:0:0: [sdd] 9770670 4096-byte logical blocks:
(40.0 GB/37.2 GiB)
[ 2471.792834] sd 4:0:0:0: Attached scsi generic sg3 type 0
[ 2471.799370]  sdd: unknown partition table
[ 2471.845582] sd 4:0:0:0: [sdd] 9770670 4096-byte logical blocks:
(40.0 GB/37.2 GiB)
[ 2471.853763] sd 4:0:0:0: [sdd] Attached SCSI disk

I was able to dd to/from the device and pull SMART data (not shown and
probably not able to share.)

If someone has "Advanced Format Developers Kit" SATA drives from
idema.org, I'd appreciate any test reports.

thanks
grant

[ patch NOT inlined because gmail will word-wrap and make a mess of
it. Please use attached filed.]

Download attachment "2.6.35-libata_4k_block_support-01" of type "application/octet-stream" (8580 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ