linux-kernel - Re: [PATCH 0/1] Recurse when searching for empty slots in resources trees

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: <alpine.LFD.2.01.0906161511390.16802@localhost.localdomain>
Date:	Tue, 16 Jun 2009 15:19:21 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Patterson <andrew.patterson@...com>
cc:	linux-pci@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jbarnes@...tuousgeek.org,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: [PATCH 0/1] Recurse when searching for empty slots in resources
 trees

On Tue, 16 Jun 2009, Andrew Patterson wrote:
>
> I recently ran into a resource collision problem where PCI hot-plug
> operations are failing for certain PCI topologies.  One case
> illustrating the problem is using a QLogic PCIe HBA in a slot with a
> PCIe root port as its parent bus.  Here is an abbreviated lspci output
> for this topology:

I think the problem is real, but the fix is wrong.

> After boot, the resource tree looks like:
> 
> f0000000-fdffffff : PCI Bus 0000:c3
>   f0000000-fdffffff : PCI Bus 0000:c2

So the problem is 9if I get this correctly) that c3 should be _inside_ c2. 
No?

But you fix it by making find_resource always go as deep as it can (if I 
read the code correctly). Which is not necessarily always what we want 
either - we've had this kind of confusion before, and the problem is that 
different users of find_resource simply want different things.

The deeper problem (I think) is that the whole "find c3 resource" thing 
should not have started from the root IN THE FIRST PLACE. I think it 
should have started from its parent resources (and then, as a special 
case, if the parent is transparent, look into the parent of the parent, 
etc - in which case it can easily end up in the root in the end, but only 
if it couldn't fit things in a parent window).

And I'm almost certain that I've seen that patch from Ivan at some point, 
but it was after the merge window closed so it didn't get merged.

Ivan? Or anybody else who remembers the patch?

		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/