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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
