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

Al Viro
2005-05-10T02:26:34Z

On Mon, May 09, 2005 at 10:07:53PM +0100, Al Viro wrote:
> u) amd64 TT is _still_ buggered due to unmap_fin.o attempts at
> magic. errno sits in TLS for amd64, so unmap_fin.o gets very interesting
> stuff leaking from libc and messing the link. IMO that should be dealt
> with by brute force; namely, unmap-$(SUBARCH).S instead of trying to
> play games with pulling stuff from libc.a. For fsck sake, we are just
> making 3 syscalls there and switcheroo() is as low-level as it gets...
> Will post once that's done...
OK, actually - C with use of _syscall(); still, per-architecture
due to different calling conventions (mmap() has enough arguments to
trigger irregularities). That deals with errno / __libc_errno getting
screwed, but there's more...

v) phys_mappings rbtree gets screwed in fixrange_init() - no
surprise, seeing what it does in
for ( ; (i < PTRS_PER_PGD) && (vaddr < end); pgd++, i++) {
pmd = (pmd_t *)pgd;
for (; (j < PTRS_PER_PMD) && (vaddr != end); pmd++, j++) {
Note that here PTR_PER_PGD and PTRS_PER_PMD are both 512. Fun... Liberal
stealing from arch/i386/mm/init.c deals with that one, AFAICS. Now we have
the following:
uml/i386 - all variants work
uml/amd64 TT-only - panics in execve() on /sbin/init (hey, a progress)
uml/amd64 other variants - work
Now to figure out WTF is happening in that execve()...