Hi!
sparc64 has for 64bit userland virtual address space
0-0x80000000000 and 0xfffff80000000000-0xfffffffc00000000 (this is mostly
hardware issue) but it is mapped int pgd into pgds 0-511 and 512-1022
respectively (because it would be dumb to have huge pgds).
Vast majority of kernel code works with this pretty well, but free_pgtables
is still broken: it just shifts the virtual addresses down by PGDIR_SHIFT
and assumes the result is correct offset into pgd, which it is not on
sparc64. This causes e.g. random crashes of 64bit statically linked apps
(which only trigger free_pgtables with common programs on sparc64).
The patch below fixes this by masking the offsets into pgd by its size.
I couldn't use (PTRS_PER_PGD-1) as a mask since alpha and sparc64 use the
last pgd for virtual PTE and thus PTRS_PER_PGD is not a power of two there,
so I introduced a new arch define. Alternatively it could be done by
((PTRS_PER_PGD-1)|1) if you wish (but it is not sure whether that would will
work with future archs).
Another issue is that some syscalls (brk, mremap, munmap, mmap) can be used
by evil application to allocate things in the virtual address hole and
confuse kernel by that quite a lot. sparc_mmap was trying to solve this a
little bit, but did not fully, while other syscalls did not bother much.
This patch should fix all this by:
- allowing arch specific get_unmapped_area, which can handle all the arch
specific details like where in virtual address space it is possible to
allocate things and where it is not.
- hacking sparc64 and sparc32 syscall stubs to these syscalls to make sure
they have proper arguments before calling generic routines (to do this, I
had unfortunately to separate sys_mremap do do_mremap and sys_mremap but I
see no other easy way how to do it without copying most of mremap.c into
sparc files which would be ugly and unmaintainable - I have to call
get_unmapped_area in some cases before calling do_mremap and thus have to
hold mm semaphore around).
sun4c and sun4 has similar issues like sparc64 has (there the VA hole is
from 0x20000000 to 0xdfffffff and perhaps some other architectures will have
something similar, so it is not sparc64 specific issue).
Please apply.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.43 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:18 EST