linux-kernel - [PATCH 2.6.20] sata_nv: don't rely on NV_INT

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, 23 Jan 2007 20:09:02 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Björn Steinbrink <B.Steinbrink@....de>,
	Robert Hancock <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Larry Walton <lwalton@...l.com>, s0348365@....ed.ac.uk,
	pomac@...or.com, chunkeey@....de, Jeff Garzik <jeff@...zik.org>
Subject: [PATCH 2.6.20] sata_nv: don't rely on NV_INT_DEV indication with ADMA

OK, here it is in full signed-off glory. Hopefully we can get this in 
for 2.6.20.

---

Several people reported issues with certain drive commands timing out on 
sata_nv controllers running in ADMA mode. The commands in question were 
non-DMA-mapped commands, usually FLUSH CACHE or FLUSH CACHE EXT.

 From experimentation it appears that the NV_INT_DEV indication isn't 
always set when a legitimate command completion interrupt is received on 
a legacy-mode command, at least not on these controllers in ADMA mode. 
When a command is pending on the port, force the flag on always in the 
irq_stat value before calling nv_host_intr so that the drive busy state 
is always checked by ata_host_intr.

This also fixes some questionable code in nv_host_intr which called 
ata_check_status when a command was pending and ata_host_intr returned 
"unhandled". If the device interrupted at just the wrong time this could 
cause interrupts to be lost.

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

View attachment "sata_nv-force-int-dev-in-interrupt.patch" of type "text/plain" (1316 bytes)