linux-kernel - Re: [PATCH] libata: handle IDE AMNF errors in the EH path

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, 15 Jul 2014 01:16:36 +0400
From:	"Alexey Asemov (Alex/AT)" <alex@...x-at.ru>
To:	"Tejun Heo" <tj@...nel.org>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libata: handle IDE AMNF errors in the EH path

Tejun Heo <tj@...nel.org> wrote at Mon, 14 Jul 2014 20:10:10 +0400:

> IIRC AMNF has been deprecated for a very long time now.  The bit isn't
> too likely to get reused given that major updates to ATA spec is
> improbable but I'm still not quite fond of adding handling of a long
> deprecated flag.  Can you please provide a bit more detail?  Which
> device was it?

The hardware is: AMD 6550M-based notebook, WD7500BPVT 2.5" 750G SATA2 hard  
drive. PCI IDs for the controller are 1022:7801 subsys 1025:059d.

I was using linux-based machine to salvage data from failing hard drive,  
and found that pure AMNF 0x01 error code generates generic "device error"  
that is retried several times by SCSI stack instead of "media error" that  
is passed up to software. That slowed down salvaging a lot, so the  
patching was done and then everything went smooth.

So I presume AMNF error code is surely not dead yet, and it's better for  
it to be handled. It is used by modern enough devices, and used properly:  
drive returned AMNF only when IDs for track cannot be read completely due  
to dying head or positioning, otherwise it returned UNC(orrectables).  
Also, there is handling code in libata-scsi.c for 0x01 AMNF error already.  
Not handling it causes excessive retries that can damage failing drivers  
further, and wrong generic error code ("device error") reporting.
--
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/