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:18:05 -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, Linus Torvalds wrote:
> 
> IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing 
> on the actual allocations.

And just to clarify - I think that while you get that error for the 
qla2xxx driver, I suspect that your actual resource tree is all good, and 
that the PCI allocations were fine.

And then the problem you his is now that the driver literally thinks that 
some other driver already took that resource.

The patch I just sent is not actually the patch I think you should do: the 
proper patch is to just remove IORESOURCE_BUSY from the e820 resources, 
simply because they are _not_ indicative of a driver already holding on to 
the resource.

Of course, the sad part is that potentially IORESOURCE_BUSY might actually 
be a really good bit for exactly that - we've had tons of issues with 
hardware sensors literally having a kernel driver _and_ a system level 
driver (ie ACPI), and things get confused exactly because there are now 
two drivers trying to drive the same piece of hardware.

But basically, if you have BAR's and the e820 resource areas co-existing, 
then the e820 resources shouldn't be marked BUSY.

Anyway - to just re-cap - you might as well just ignore the patch I just 
sent out, and instead just avoid doing that BUSY bit to begin with in the 
"late e820" case. Simpler and more correct.

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