From: H. Peter Anvin on
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

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

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