linux-kernel - Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

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:	Fri, 29 Aug 2008 23:11:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	David Witbrodt <dawitbro@...global.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit
 a2bd7274b47124d2fc4dfdb8c0591f545ba749dd



On Fri, 29 Aug 2008, Yinghai Lu wrote:
> 
> please check
> 
>   __request_region: conflict: (reserved) [dd000000, efffffff], res:
> (qla2xxx) [ddffc000, ddffffff]
> busy flag
> qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]

Ok, this is actually when the driver wants to reserve the BAR, and then it 
norices that there is an existing "reservation" there.

So yes, drivers will care - they literally will think that somebody else 
owns their resource if they have a BUSY resource inside of them. So this 
is a driver protecting against another driver.

The sad part is that it looks like it's entirely due to the PCI code 
trying to emulate an ISA driver model, and use a flat resource space - so 
it hits the upper resources first.

Does this patch make a difference? It actually removes a fair chunk of 
code, by just saying "we really don't care if the resource is IO or MEM, 
we just want to reserve space inside of it, regardless of type".

Untested - obviously.

		Linus

---
 drivers/pci/pci.c |   26 +++++++++-----------------
 1 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c9884bb..a3de4fe 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1304,15 +1304,11 @@ pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge)
 void pci_release_region(struct pci_dev *pdev, int bar)
 {
 	struct pci_devres *dr;
+	struct resource *res = pdev->resource + bar;
 
 	if (pci_resource_len(pdev, bar) == 0)
 		return;
-	if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
-		release_region(pci_resource_start(pdev, bar),
-				pci_resource_len(pdev, bar));
-	else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM)
-		release_mem_region(pci_resource_start(pdev, bar),
-				pci_resource_len(pdev, bar));
+	__release_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar));
 
 	dr = find_pci_dr(pdev);
 	if (dr)
@@ -1336,20 +1332,16 @@ void pci_release_region(struct pci_dev *pdev, int bar)
 int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
 {
 	struct pci_devres *dr;
+	struct resource *res = pdev->resource + bar;
 
 	if (pci_resource_len(pdev, bar) == 0)
 		return 0;
-		
-	if (pci_resource_flags(pdev, bar) & IORESOURCE_IO) {
-		if (!request_region(pci_resource_start(pdev, bar),
-			    pci_resource_len(pdev, bar), res_name))
-			goto err_out;
-	}
-	else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
-		if (!request_mem_region(pci_resource_start(pdev, bar),
-				        pci_resource_len(pdev, bar), res_name))
-			goto err_out;
-	}
+
+	if (!res->parent)
+		goto err_out;
+
+	if (!__request_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar), res_name))
+		goto err_out;
 
 	dr = find_pci_dr(pdev);
 	if (dr)
--
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/