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]
Date:	Sun, 14 Jan 2007 20:40:01 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org
Cc:	Jeff Garzik <jeff@...zik.org>, Allen Martin <AMartin@...dia.com>
Subject: [PATCH -mm] sata_nv: cleanup ADMA error handling

Should apply to -mm tree or current libata-dev git tree. Sorry for 
attaching, but I seem to have misplaced the magic incantations to make 
Thunderbird not destroy inline patches..

---

This cleans up a few issues with the error handling in sata_nv in ADMA 
mode to make it more consistent with other NCQ-capable drivers like ahci 
and sata_sil24:

-When a command failed, we would effectively set AC_ERR_DEV on the 
queued command always. In the case of NCQ commands this prevents libata 
from doing a log page query to determine the details of the failed 
command, since it thinks we've already analyzed. Just set flags in the 
port ehi->err_mask, then freeze or abort and let libata figure out what 
went wrong.

-The code handled NV_ADMA_STAT_CPBERR as a "really bad error" which 
caused it to set error flags on every queued command. I don't know 
exactly what this flag means (no docs, grr!) but from what I can guess 
from the standard ADMA spec, it just means that one or more of the CPBs 
had an error, so we just need to go through and do our normal checks in 
this case.

-In the error_handler function the code would always go through and do 
an ADMA channel reset and also dump out the state of all the CPBs. This 
reset seems heinous in this situation since we haven't even decided to 
reset anything yet. The output seems redundant at this point since 
libata already dumps the state of all active commands on errors (and it 
also triggers at times when it shouldn't, like when suspending). Do the 
ADMA reset only on hardreset and remove the output.

Signed-off-by: Robert Hancock <hancockr@...w.ca>


View attachment "sata_nv-cleanup-error-handling.patch" of type "text/plain" (8000 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ