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

[Al Viro]

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()...
-
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/