x86, hweight: Fix UML boot crash
in [Kernel]
|
Prev: [PATCH 2/3] drivers/staging: Use GFP_ATOMIC when a lock is held
Next: kgdb debugger proxy question - using the same serial port for both serial console and kgdb
From: H. Peter Anvin on 30 May 2010 17:20 On 05/30/2010 01:17 PM, Borislav Petkov wrote: >>> This bothers me, because it really feels like something is fundamentally >>> broken in UML tryingto track the upstream architecture, and this is just >>> a bandage. >> >> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML >> special cases in x86 just because they include it. >> >> Which begs the question why _is_ UML sucking in x86 stuff and can anyone >> provide us with some sensible reasons? Because if there aren't any, it >> is their includes that should be fixed. Let me see what I can do to >> redirect hweight stuff properly... > > Ok, AFAICT UML is sucking in the includes of the sub-architecture the > UML "guest" is running on. See below¹ for the whole gcc string make > executes. Among the switches is > > "-I/home/boris/kernel/linux-2.6/arch/x86/include" > > so there will be no untangling today. Instead, we could do another > bandaid which is confined to UML include space only and redirect > arch_hweight.h includes to the generic ones. Check this out, it seems to > work here: > That looks better to me, although I'm still wondering why UML can't stomach the register-saving tricks... it is not at all "obvious" why that can't be done. Perhaps we can get Jeff to comment on this? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Toralf Förster on 31 May 2010 10:00 Borislav Petkov wrote at 22:17:38 > LKML-Reference: <201005271944.09541.toralf.foerster(a)gmx.de> > Signed-off-by: Borislav Petkov <bp(a)alien8.de> > --- > arch/um/include/asm/arch_hweight.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > create mode 100644 arch/um/include/asm/arch_hweight.h > > diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h > new file mode 100644 > index 0000000..c656cf4 > --- /dev/null > +++ b/arch/um/include/asm/arch_hweight.h > @@ -0,0 +1,6 @@ > +#ifndef _ASM_UM_HWEIGHT_H > +#define _ASM_UM_HWEIGHT_H > + > +#include <asm-generic/bitops/arch_hweight.h> > + > +#endif > This patch does not to solve the reported issue by me. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Dike on 31 May 2010 10:20 On Sun, May 30, 2010 at 09:39:56PM +0200, Borislav Petkov wrote: > Which begs the question why _is_ UML sucking in x86 stuff and can anyone > provide us with some sensible reasons? Because if there aren't any, it > is their includes that should be fixed. Let me see what I can do to > redirect hweight stuff properly... Generally, UML pulls in the host arch headers because they work. When they are only architecture-dependent (and not, say, depending on the host task struct or something), they're fine. What's the include path from UML to the x86 hweight stuff? Jeff -- Work email - jdike at linux dot intel dot com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 31 May 2010 10:20 From: Toralf F�rster <toralf.foerster(a)gmx.de> Date: Mon, May 31, 2010 at 09:55:53AM -0400 > Borislav Petkov wrote at 22:17:38 > > LKML-Reference: <201005271944.09541.toralf.foerster(a)gmx.de> > > Signed-off-by: Borislav Petkov <bp(a)alien8.de> > > --- > > arch/um/include/asm/arch_hweight.h | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > create mode 100644 arch/um/include/asm/arch_hweight.h > > > > diff --git a/arch/um/include/asm/arch_hweight.h b/arch/um/include/asm/arch_hweight.h > > new file mode 100644 > > index 0000000..c656cf4 > > --- /dev/null > > +++ b/arch/um/include/asm/arch_hweight.h > > @@ -0,0 +1,6 @@ > > +#ifndef _ASM_UM_HWEIGHT_H > > +#define _ASM_UM_HWEIGHT_H > > + > > +#include <asm-generic/bitops/arch_hweight.h> > > + > > +#endif > > > This patch does not to solve the reported issue by me. Did you do 'make mrproper' before rebuilding UML with it? Also, can you do grep -EriIn 'x86.*hweight\.h' arch/um/ after having applied the patch? You shouldn't be getting any matches. If it still fails then, then it is something else since with this patch, UML includes the standard hweight* routines. -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Toralf Förster on 31 May 2010 10:40
Borislav Petkov wrote at 16:10:58 > Did you do 'make mrproper' before rebuilding UML with it? Yes, I did "make mrproper ARC H= um" and "make mrproper" > Also, can you do > > grep -EriIn 'x86.*hweight\.h' arch/um/ tfoerste(a)n22 ~/devel/linux-2.6 $ grep -EriIn 'x86.*hweight\.h' arch/um/ tfoerste(a)n22 ~/devel/linux-2.6 $ And here : tfoerste(a)n22 ~/devel/linux-2.6 $ tail arch/um/include/asm/arch_hweight.h #ifndef _ASM_UM_HWEIGHT_H #define _ASM_UM_HWEIGHT_H #include <asm-generic/bitops/arch_hweight.h> #endif What I get is this : tfoerste(a)n22 ~/devel/linux-2.6 $ ./linux Locating the bottom of the address space ... 0x1000 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - NONE hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /dev/shm/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Adding 20832256 bytes to physical memory to account for exec-shield gap Linux version 2.6.35-rc1 (tfoerste(a)n22) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) ) #1 Mon May 31 16:33:40 CEST 2010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 13174 Kernel command line: root=98:0 PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 28816k available Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:15 Calibrating delay loop... 4679.27 BogoMIPS (lpj=23396352) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Using 2.6 host AIO NET: Registered protocol family 16 bio: create slab <bio-0> at 0 Switching to clocksource itimer NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. mconsole (version 2) initialized on /home/tfoerste/.uml/xpp9B9/mconsole Checking host MADV_REMOVE support...OK UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer) Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) Installing knfsd (copyright (C) 1996 okir(a)monad.swb.de). msgmni has been set to 56 alg: No test for stdrng (krng) io scheduler noop registered io scheduler cfq registered (default) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk(a)qualcomm.com> TCP cubic registered NET: Registered protocol family 17 Initialized stdio console driver Console initialized on /dev/tty0 console [tty0] enabled Initializing software serial port version 1 console [mc-1] enabled Couldn't stat "root_fs" : err = 2 Failed to initialize ubd device 0 :Couldn't determine size of device's file VFS: Cannot open root device "98:0" or unknown-block(98,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0) 0ac5af10: [<08286f60>] panic+0x60/0xd9 0ac5af28: [<080499f4>] mount_block_root+0x160/0x286 0ac5af64: [<080e04f7>] sys_mknod+0x27/0x30 0ac5af78: [<08049b75>] mount_root+0x5b/0x60 0ac5af8c: [<08049c8c>] prepare_namespace+0x112/0x185 0ac5afa4: [<080491cc>] kernel_init+0x108/0x12e 0ac5afbc: [<0806ec90>] run_kernel_thread+0x30/0x60 0ac5afd8: [<0806ec7f>] run_kernel_thread+0x1f/0x60 0ac5afe4: [<0805d37b>] new_thread_handler+0x6b/0xa0 0ac5afe8: [<080490c4>] kernel_init+0x0/0x12e EIP: 0073:[<b784e424>] CPU: 0 Not tainted ESP: 007b:bfccdbdc EFLAGS: 00000246 Not tainted EAX: 00000000 EBX: 00004793 ECX: 00000013 EDX: 00004793 ESI: 0000478f EDI: 0000003b EBP: bfccdc68 DS: 007b ES: 007b 0ac5aeec: [<0809a074>] notifier_call_chain+0x34/0x70 0ac5af10: [<08286f88>] panic+0x88/0xd9 0ac5af28: [<080499f4>] mount_block_root+0x160/0x286 0ac5af64: [<080e04f7>] sys_mknod+0x27/0x30 0ac5af78: [<08049b75>] mount_root+0x5b/0x60 0ac5af8c: [<08049c8c>] prepare_namespace+0x112/0x185 0ac5afa4: [<080491cc>] kernel_init+0x108/0x12e 0ac5afbc: [<0806ec90>] run_kernel_thread+0x30/0x60 0ac5afd8: [<0806ec7f>] run_kernel_thread+0x1f/0x60 0ac5afe4: [<0805d37b>] new_thread_handler+0x6b/0xa0 0ac5afe8: [<080490c4>] kernel_init+0x0/0x12e Segmentation fault (core dumped) -- MfG/Sincerely Toralf F�rster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |