linux-kernel - Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

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]

Message-ID: <459AEE36.7080500@pobox.com>
Date:	Tue, 02 Jan 2007 18:43:50 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Alan <alan@...rguk.ukuu.org.uk>
CC:	Linus Torvalds <torvalds@...l.org>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and
 v2.6.20-rc3 released))

Alan wrote:
>> 2.6.0 - 2.6.19:  libata guarantees that all PCI BARs are reserved to the 
>> libata driver.
> 
> Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
> BAR 0 to BAR 3 of a compatibility mode controller

(a) I'm well of aware of this, and (b) that changes nothing.

I said "PCI BARs" for a reason.  libata was written according to the 
following model:

	1) Programmatically reserve /all/ resources associated with
	   our PCI device
	2) Manually reserve resources associated with our PCI device,
	   but are not listed in struct pci_dev.

You have changed this to:

	1) Manually reserve /some/ resources associated with PCI device
	2) Manually reserve resources associated with our PCI device,
	   but are not listed in struct pci_dev.

But then 2.6.21 goes back to:

	1) Programmatically reserve /all/ resources associated with
	   our PCI device
	2) Manually reserve resources associated with our PCI device,
	   but are not listed in struct pci_dev.

Maybe I can say it more clearly by telling you how to fix the regression 
you have introduced:  Loop through all BAR resources in struct pci_dev, 
and reserve them if they are not already reserved by libata earlier in 
the code.  There.  Regression fixed.

(but then we rewrite this code again in 2.6.21)

> You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
> never request the legacy BAR 1 and BAR 3 because they were erased by the
> PCI quirk code and thus never claim the other port. Thats been a bug since
> day one but it never seemed worth fixing in the short term.

Yes -- that's a bug, one that existed prior to the "it doesn't boot" 
combined mode regression everybody complained about.  I'm talking about 
a new regression just introduced via 
dc3c3377f03634d351fafdfe35b237b283586c04, not a old bug that existed 
prior to the regression introduced in 
368c73d4f689dae0807d0a2aa74c61fd2b9b075f.

	Jeff

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