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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ