Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

Al Viro
2005-05-08T00:18:39Z

On Sat, May 07, 2005 at 02:03:56PM -0400, Jeff Dike wrote:
> On Sat, May 07, 2005 at 05:57:48PM +0200, Alexander Nyberg wrote:
> > I never get uml to compile around here, 2.6.12-rc3 + that patchkit from
> > the link you sent blows up with defconfig any my minimal config. Please
> > attach your guest .config and if you can you might aswell put your guest
> > vmlinux somewhere where i can download it too.
>
> Start with -rc3, and all the patches from
> http://user-mode-linux.sf.net/patches.html
> up to and including skas0. You'll see a note to x86_64 users on that patch.

Hrm...
a) stub.S handling breaks on O= builds. Actually, your unprofile
breaks there - it's bypassing the machinery that deals with include path.
b) stub_segv.c on amd64 includes <signal.h>. Not a good idea...
c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user()
that needs updating (AFAICS, you have that in your patchset, but it hadn't
reached Linus)
d) ip_compute_csum() prototype is missing (same file)
e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h
f) take a good look at UPT_SET() in the same file ;-)
g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in
sys-x86_64/Makefile needs to be removed.
h) Makefile.rules should be included _after_ SYMLINKS = in the same
file.
i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(),
include of linux/module.h and barriers in your delay loop bodies (or games
with volatile - anything that would guarantee that gcc won't decide to optimize
the entire loop away). The last part applies to i386 as well.
j) ip_compute_csum should be exported on amd64.
k) sys-x86_64/syscalls.c needs include "kern.h"
l) elf-i386.h should include <asm/user.h>, not "user.h"
m) elf-x86_64.h lacks R_X86_64_... definitions
n) WTF _is_ that #ifdef TIF_IA32 in there? Aside of the trailing \,
we could as well put #error there - free-floating clear_thread_flag(TIF_IA32);
outside of any function body will have that effect anyway.
o) in drivers/chan_kern.c we have several printf(KERN_ERR "...");
these should become printk, as they clearly had been intended. As it is,
they give instant panic if we ever call them.
p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset
has it, but same patch in Linus' tree does not.

I've got patches for everything except (a); that one is really nasty. I hope
to sort it out by tonight; if not, I'll just send what I've got by now.