These are some trivial fixes for the x86-64 subarch module support. The only
potential problem is that I have to modify arch/x86_64/kernel/module.c, to
avoid copying the whole of it.
I can't use it verbatim because it depends on a special vmalloc-like area for
modules, which for now (maybe that's to fix, I guess not) UML/x86-64 has not.
I went the easy way and reused the i386 vmalloc()-based allocator.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch does some totally trivial compilation fixes. It also restores the
debugregs manipulation, which was commented out simply because it doesn't
compile on x86_64 (we haven't yet implemented there debugregs handling).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is for -mm only. It should probably be included in git-audit,
and should be forwarded to Linus iff git-audit is.
It updates the audit-syscall-{entry,exit} calls to current -mm.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Add some commentary about UML internals, for a strange trick.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Cleanup: make an inline of this empty proc.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We want to make possible, for the user, to enable the i586 AES implementation.
This requires a restructure.
- Add a CONFIG_UML_X86 to notify that we are building a UML for i386.
- Rename CONFIG_64_BIT to CONFIG_64BIT as is used for all other archs
- Tell crypto/Kconfig that UML_X86 is as good as X86
- Tell it that it must exclude not X86_64 but 64BIT, which will give the
same results.
- Tell kbuild to descend down into arch/i386/crypto/ to build what's needed.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Prevent the kernel from oopsing during the extable sorting, as it can do
now, because the extable is in the readonly section of the binary.
Jeff says: The exception table turned RO in 2.6.11-rc3-mm1 for some reason.
Moving it causes it to land in the writable data section of the binary.
Paolo says: This patch fixes a oops on startup, which can be easily
triggered by compiling with CONFIG_MODE_TT disabled, and STATIC_LINK either
disabled or enabled. The resulting kernel will always Oops on startup,
after printing this simple output:
I've verified, by binary search on the BitKeeper repository (synced up as
of 2.6.12-rc2), starting from the range 2.6.11-2.6.12-rc1, that this bug
shows up on BitKeeper revisions in the range [@1.1994.11.168,+inf), i.e.
starting from this:
[PATCH] lib/sort: Replace insertion sort in exception tables
Since UML does not use the exception table, it's likely that insertion sort
didn't happen to write anything on the table.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Replace misleading definition of FIRST_USER_PGD_NR 0 by definition of
FIRST_USER_ADDRESS 0 in all the MMU architectures beyond arm and arm26.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
