linux-kernel - Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

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: <alpine.LFD.1.10.0808292010260.5010@nehalem.linux-foundation.org>
Date:	Fri, 29 Aug 2008 20:15:35 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	David Witbrodt <dawitbro@...global.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit
 a2bd7274b47124d2fc4dfdb8c0591f545ba749dd



On Fri, 29 Aug 2008, Linus Torvalds wrote:
> 
> and while I still haven't actually tested it, it looks sane and compiles 
> to code that also looks sane.

.. and it even works (apart from a missing '\n' for the expansion report 
;).

I tested it with the appended silly test-case, and it shows

	...
	 BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
	 BIOS-e820: 0000000100000000 - 0000000160000000 (usable)
	Expanded resource Kernel dummy due to conflict with Kernel code
	Expanded resource Kernel dummy due to conflict with Kernel data
	last_pfn = 0x160000 max_arch_pfn = 0x3ffffffff
	x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
	...

and /proc/iomem shows

	...
	00100000-9cf64fff : System RAM
	  00200000-006ea27f : Kernel dummy
	    00200000-00561f37 : Kernel code
	    00561f38-006ea27f : Kernel data
	  00777000-007d6cc7 : Kernel bss
	...

so it correctly expanded that "Kernel dummy" resource to cover the 
resources it had clashed with.

And no, it's not perfect. We certainly _could_ split things instead. But I 
hope that odd "e820 resources were bogus" case almost never would actually 
trigger in practice, and the expansion case is not only simpler, it's also 
slightly more robust in the sense that a single big resource is likely to 
fit the things we need than multiple smaller resources that have been 
chopped up.

		Linus

--- dummy test patch for the 'insert-resource-expand-to-fit' thing ---
 arch/x86/kernel/setup.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 362d4e7..6265a38 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -578,6 +578,14 @@ static struct x86_quirks default_x86_quirks __initdata;
 
 struct x86_quirks *x86_quirks __initdata = &default_x86_quirks;
 
+static struct resource dummy_resource = {
+	.name	= "Kernel dummy",
+	.start	= 0,
+	.end	= 0,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+};
+
+
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
@@ -665,6 +673,9 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(&__bss_start);
 	bss_resource.end = virt_to_phys(&__bss_stop)-1;
 
+	dummy_resource.start = code_resource.end - 1024;
+	dummy_resource.end = data_resource.start + 1024;
+
 	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 
@@ -704,6 +715,8 @@ void __init setup_arch(char **cmdline_p)
 	insert_resource(&iomem_resource, &data_resource);
 	insert_resource(&iomem_resource, &bss_resource);
 
+	insert_resource_expand_to_fit(&iomem_resource, &dummy_resource);
+
 	if (efi_enabled)
 		efi_init();
 
--
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/