linux-kernel - Re: [PATCH 05/11] 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: Windows password security audit tool. GUI, reports in PDF.

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

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

* Yinghai Lu <yinghai@...nel.org>:
> 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.

I agree with Jesse and Bjorn. I really hate introducing a new
command line param.

The goal here should be to do the right thing, all the time,
without requiring command line parameters.

I understand that you are avoiding a change to existing behavior
by defaulting to try=1.

What I don't understand is how you expect your change to benefit
any actual users. The usage model you propose is:

	- user encounters failure

	- user emails lkml/linux-pci and says "why doesn't my
	  device get resources?"

	- we tell user, "please reboot with try=N for increasing
	  values of N until it works"

Why shouldn't we be aggressive all the time?

If this patch series is going to be accepted, we should turn it
on all the time. Everyone will get the benefits.

If it breaks machines, depending on the bug reports, it will end
up either:

	a) we missed an implementation detail (easily fixed)

	or 

	b) the design/strategy is wrong, in which case we need to
	take a step back and think about a different approach to
	solve the problem you're trying to solve

For this patch, I don't mind the changes to
pci_assign_unassigned_resources(), but I really do not agree with
the configurability introduced in pci_setup().

thanks,
/ac
--
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/