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  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, 15 Jan 2010 21:38:47 -0700
From:	Alex Chiang <>
To:	Yinghai Lu <>
Cc:	Jesse Barnes <>,
	Ingo Molnar <>,
	Linus Torvalds <>,
	Ivan Kokshaysky <>,
	Kenji Kaneshige <>,
	Bjorn Helgaas <>,,
Subject: Re: [PATCH 05/11] pci: update bridge res to get more big range in
	pci assign unssign

* Yinghai Lu <>:
> 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)


	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().

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists