linux-kernel - Re: [RFC] pata

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070408195956.4e7d50c0@the-village.bc.nu>
Date:	Sun, 8 Apr 2007 19:59:56 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [RFC] pata_icside driver

> The second FIXME area is ata_irq_ack - it is unconditionally coded
> for SFF-type interfaces.  I believe that using this function in
> non-BMDMA interfaces is wrong - it attempts to read from the BMDMA
> registers irrespective of whether ap->ioaddr.bmdma_addr is set or
> not.  The question this poses is: what should non-BMDMA implementations
> use for this method?  Note that pata_platform also uses this
> function despite not supporting BMDMA which seems even more suspicious.

Thats a bug that has arrived again. The older code was corrected to
handle this properly but the fix appears to have become lost. The
ioread/iowrite code actually made quite a mess (all the address reporting
is also broken) and we do some iffy things like compare the iomap result
with zero and assume thats the same as checking for true bus zero
addresses.

ata_irq_ack is part of the SFF layer so its fine that it assumes SFF but
its wrong that it is used unconditionally and it shouldn't be used this
way. It just needs a (!ap->ioaddr.bmdma_addr) test adding (assuming thats
valid for iomap)

Alan
-
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/