Re: linux 2.6.27 kernel panic on x86 - please revert commit3a85e770aa77e4f1a4096275c97b64c10cd7323e

[Ingo Molnar]

* Jeff Chua <jeff.chua.linux@xxxxxxxxx> wrote:

> Commit 3a85e770aa77e4f1a4096275c97b64c10cd7323e broke linux boot on 
> x86 resulting in kernel panic. Here's the console output ...
>
> Net: Registered protocol family 17
> Using IPI No-Shortcut mode
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem (readonly).
> Freeing unsued kernel memory: 312k freed
> init[1]: segfault at ffffe01c up b7f0dc28 sp bfc26628 error 5 in ld-2.7.90.so[b7f0b000+1c000]
> Kernel panic - not syncing: Attempted to kill init!

hm, ffffe01c is weird - VDSO on some ancient distro perhaps? Do you have 
CONFIG_COMPAT_VDSO=y enabled?

if you have CONFIG_COMPAT_VDSO=y enabled but the read access still 
faults, then the question is, why is ffffe000 not mapped properly? The 
logic in arch/x86/vdso/vdso32-setup.c and map_compat_vdso() / 
arch_setup_additional_pages() seems correct and should result in the 
VDSO being mapped as user-readable.

The revert probably just works around some other bug - it is dangerous 
to keep a generic-sounding page table constant like PTE/PDE_IDENT_ATTR 
with user bits set - if that ever leaks through to user-space, surviving 
pagetable init, we've got a root hole.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/