linux-kernel - Re: [stable] 2.6.23 boot failures on x86-64.

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.0.999.0710291123200.30120@woody.linux-foundation.org>
Date:	Mon, 29 Oct 2007 11:37:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Martin Ebourne <fedora@...urne.me.uk>,
	Zou Nan hai <nanhai.zou@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Andi Kleen <ak@...e.de>, stable@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>,
	Andy Whitcroft <apw@...dowen.org>, Mel Gorman <mel@....ul.ie>
Subject: Re: [stable] 2.6.23 boot failures on x86-64.



On Mon, 29 Oct 2007, Greg KH wrote:
> 
> I'll be glad to revert it in -stable, if it's also reverted in Linus's
> tree first :)

We've had some changes since 2.6.23, and afaik, the 
"alloc_bootmem_high_node()" code is alreadt effectively dead there. It's 
only called if CONFIG_SPARSEMEM_VMEMMAP is *not* enabled, and I *think* we 
enable it by force on x86-64 these days.

More people added to Cc, just to clarify whether I'm just confused.

Andy, Christoph, Mel: commit 2e1c49db4c640b35df13889b86b9d62215ade4b6 aka 
"x86_64: allocate sparsemem memmap above 4G" is the one that causes the 
failures, just fyi.

Martin - it would be great if you could try out your failing machine with 
2.6.24-rc1 (or a nightly snapshot or current git.. the more recent the 
better).

But if I'm right, that commit should be reverted from 2.6.24 just because 
it's pointless (even if the bug itself is gone). And if I'm wrong, it 
should be reverted. So something like the appended would make sense 
regardless.

Can I get a "tested-by"? And/or ack/nack's on my half-arsed theory above?

		Linus
--
From: Linus Torvalds <torvalds@...dy.linux-foundation.org>

Revert "x86_64: allocate sparsemem memmap above 4G"

This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6, since
testing in Fedora has shown it to cause boot failures, as per Dave
Jones. Bisected down by Martin Ebourne.

Cc: Dave Jones <davej@...hat.com>
Cc: Martin Ebourne <fedora@...urne.me.uk>
Cc: Zou Nan hai <nanhai.zou@...el.com>
Cc: Suresh Siddha <suresh.b.siddha@...el.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 1e3862e..a7308b2 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -728,12 +728,6 @@ int in_gate_area_no_task(unsigned long addr)
 	return (addr >= VSYSCALL_START) && (addr < VSYSCALL_END);
 }
 
-void * __init alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
-{
-	return __alloc_bootmem_core(pgdat->bdata, size,
-			SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
-}
-
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
 	if (vma->vm_mm && vma->vm_start == (long)vma->vm_mm->context.vdso)
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index c83534e..0365ec9 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -59,7 +59,6 @@ extern void *__alloc_bootmem_core(struct bootmem_data *bdata,
 				  unsigned long align,
 				  unsigned long goal,
 				  unsigned long limit);
-extern void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size);
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
 extern void reserve_bootmem(unsigned long addr, unsigned long size);
diff --git a/mm/sparse.c b/mm/sparse.c
index 08fb14f..e06f514 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -220,12 +220,6 @@ static int __meminit sparse_init_one_section(struct mem_section *ms,
 	return 1;
 }
 
-__attribute__((weak)) __init
-void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
-{
-	return NULL;
-}
-
 static unsigned long usemap_size(void)
 {
 	unsigned long size_bytes;
@@ -267,11 +261,6 @@ struct page __init *sparse_mem_map_populate(unsigned long pnum, int nid)
 	if (map)
 		return map;
 
-  	map = alloc_bootmem_high_node(NODE_DATA(nid),
-                       sizeof(struct page) * PAGES_PER_SECTION);
-	if (map)
-		return map;
-
 	map = alloc_bootmem_node(NODE_DATA(nid),
 			sizeof(struct page) * PAGES_PER_SECTION);
 	return map;
-
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/