Greg Freemyer wrote:
On Sun, Nov 2, 2008 at 8:21 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
Greg Freemyer wrote:
On Fri, Oct 31, 2008 at 1:49 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
Notes:
1) 1.5TB drive fix from Roland
2) Tejun's sata_via brings a non-working via configuration thanks to a
new facility also being used in recent (ICH9/10) ata_piix.
Change is longer than one might like, but it accurately describes the
hardware now, the previous stuff wasn't working, and the newly added
support code shouldn't touch non-broken VIA controllers.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c | 1 -
drivers/ata/libata-core.c | 11 +++-
drivers/ata/sata_via.c | 155
+++++++++++++++++++++++++++++++++++++++++----
include/linux/libata.h | 1 +
4 files changed, 152 insertions(+), 16 deletions(-)
Jens Axboe (1):
libata: add whitelist for devices with known good pata-sata bridges
Randy Dunlap (1):
ATA: remove excess kernel-doc notation
Roland Dreier (1):
libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127
Tejun Heo (1):
sata_via: fix support for 5287
<snip>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 2ff633c..82af701 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1268,7 +1268,7 @@ u64 ata_tf_to_lba48(const struct ata_taskfile *tf)
sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
- sectors |= (tf->hob_lbal & 0xff) << 24;
+ sectors |= ((u64)(tf->hob_lbal & 0xff)) << 24;
sectors |= (tf->lbah & 0xff) << 16;
sectors |= (tf->lbam & 0xff) << 8;
sectors |= (tf->lbal & 0xff);
<snip>
That looks really serious.
What happens with all previous / stable kernels when connecting up a
1.5TB drive and the user tries to use the last portion of the drive?
tf-to-lba48 is a far less common operation, generally used for error
reporting (and in Host-Protected Area code as well, it appears).
Jeff
So are you saying it is not on any data read / write paths?
Or that it is only on rarely used data read/write paths?
Because if this is on a data read/write path at all, it looks like it
could cause major data corruption with 1.5 TB drives (or larger).
..
It's on the initialization path for all lba48 devices which have
a configured HPA (Host Protected Area, mostly seen in brand-name
consumer-level systems).
The data it generates is then used on subsequent R/W commands.
I recommend the fix be backported for earlier kernels.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
