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] [day] [month] [year] [list]
Date:	Mon, 11 Feb 2008 23:38:25 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>, matthew@....cx,
	arjan@...radead.org, hancockr@...w.ca,
	torvalds@...ux-foundation.org, greg@...ah.com, tcamuso@...hat.com,
	grundler@...isc-linux.org, loic@...i.com, bunk@...nel.org,
	benh@...nel.crashing.org, ink@...assic.park.msu.ru, gregkh@...e.de,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	linux-pci@...ey.karlin.mff.cuni.cz, mj@....cz
Subject: Re: [PATCH] Change pci_raw_ops to pci_raw_read/write


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > please check some updated patches in -mm that could be affected. 
> > hope it could save you some time
> > 
> > x86-validate-against-acpi-motherboard-resources.patch
> > x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch
> > x86-mmconf-enable-mcfg-early.patch
> > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch
> 
> I have unhappy feelings here - the patches seem to be churning a bit 
> and when I last sent them to Greg and Ingo they received no apparent 
> response.

i actually carried them for a while and 
validate-against-acpi-motherboard-resources.patch got a fair bit of test 
time with positive results. So it has a clear ACK from me.

It's something that looks appealing:

| This path adds validation of the MMCONFIG table against the ACPI 
| reserved motherboard resources. If the MMCONFIG table is found to be 
| reserved in ACPI, we don't bother checking the E820 table.  The PCI 
| Express firmware spec apparently tells BIOS developers that 
| reservation in ACPI is required and E820 reservation is optional, so 
| checking against ACPI first makes sense.  Many BIOSes don't reserve 
| the MMCONFIG region in E820 even though it is perfectly functional, 
| the existing check needlessly disables MMCONFIG in these cases.

anything that isolates Linux from BIOS messups should be music to our 
ears.

i also think the mmconf-enable stuff for Barcelona stuff from Yinghai, 
albeit not particularly pretty, is probably good too for similar 
reasons. It makes the kernel boot with noacpi which is a good sign IMO. 

I have testsystems that simply do not boot with ACPI turned off - and i 
have a testsystem that locks up hard if it takes an NMI in certain ACPI 
AML sequences ... Just Because.

So i'd ACK them just on general principle - earlier versions of the 
patches were carried in x86.git and caused no particular problems.

but ... then we got complaints from you that stuff collides and that 
such patches should be carried in your or Greg's tree, so we dropped 
them. And there was another 100 KLOC of x86 code to worry about ;-)

So i'd suggest to send those patches upstream, they are system enablers 
and they are at fundamental enough places to be apparent if they cause 
any breakage i think.

	Ingo
--
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