linux-kernel - Re: [PATCH 08/14] pci: update bridge res to get more big range in pci assign unssign

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jan 2010 11:12:54 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Alex Chiang <achiang@...com>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 08/14] pci: update bridge res to get more big range in
 pci assign unssign

On Tue, 22 Dec 2009 15:02:28 -0800
Yinghai Lu <yinghai@...nel.org> wrote:

> BIOS separate IO range between several IOHs, and on some slots, BIOS
> assign the resource to the bridge, but stop assigning resource to the
> device under that bridge, because the device need big resource.
> 
> 1. pci assign unassign and record the failed device resource.
> 2. clear the BIOS assigned resource of the parent bridge of fail
> device 3. go back and call pci assign unsigned
> 4. if it still fail, will go up more bridges. and clear and try again.
> 
> use pci_try_num to control back track bridge levels.
> 
> -v2: update it with resource_list_x
> -v3: make pci_try_num default to 1. and when pci_try_num is set to
> more than 1 will check it with max_depth, and adjust that to make
> sure it is bigger enough

I really don't like the 'try' argument.  Either we can assign the
resource or not; 'try=' just makes the whole thing scarier, as if we
expect problems if we release too many resources.  If that's the case,
then the whole approach must be flawed, since it means we're not taking
into account some resources, or we're missing something about the
system configuration.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/