Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 10月, 2007 1 次提交
    • S
      kbuild: enable 'make AFLAGS=...' to add additional options to AS · 222d394d
      由 Sam Ravnborg 提交于 
      The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of AFLAGS with KBUILD_AFLAGS all over
the tree.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      222d394d
  3. 15 10月, 2007 1 次提交
    • S
      kbuild: enable 'make CFLAGS=...' to add additional options to CC · a0f97e06
      由 Sam Ravnborg 提交于 
      The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.

One usecase is when trying to find gcc bugs but other
use cases has been requested too.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k

Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      a0f97e06
  5. 11 10月, 2007 13 次提交
  7. 19 8月, 2007 1 次提交
  9. 22 7月, 2007 1 次提交
    • A
      x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu · 2aae950b
      由 Andi Kleen 提交于 
      This implements new vDSO for x86-64.  The concept is similar
to the existing vDSOs on i386 and PPC.  x86-64 has had static
vsyscalls before,  but these are not flexible enough anymore.

A vDSO is a ELF shared library supplied by the kernel that is mapped into
user address space.  The vDSO mapping is randomized for each process
for security reasons.

Doing this was needed for clock_gettime, because clock_gettime
always needs a syscall fallback and having one at a fixed
address would have made buffer overflow exploits too easy to write.

The vdso can be disabled with vdso=0

It currently includes a new gettimeofday implemention and optimized
clock_gettime(). The gettimeofday implementation is slightly faster
than the one in the old vsyscall.  clock_gettime is significantly faster
than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.

The new calls are generally faster than the old vsyscall.

Advantages over the old x86-64 vsyscalls:
- Extensible
- Randomized
- Cleaner
- Easier to virtualize (the old static address range previously causes
overhead e.g. for Xen because it has to create special page tables for it)

Weak points:
- glibc support still to be written

The VM interface is partly based on Ingo Molnar's i386 version.

Includes compile fix from Joachim Deguara
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2aae950b
  11. 03 5月, 2007 2 次提交
  13. 16 12月, 2006 1 次提交
    • L
      Remove stack unwinder for now · d1526e2c
      由 Linus Torvalds 提交于 
      It has caused more problems than it ever really solved, and is
apparently not getting cleaned up and fixed.  We can put it back when
it's stable and isn't likely to make warning or bug events worse.

In the meantime, enable frame pointers for more readable stack traces.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1526e2c
  15. 07 12月, 2006 1 次提交
    • A
      [PATCH] x86-64: Add option to compile for Core2 · 71381998
      由 Andi Kleen 提交于 
      Add an option to compile for Intel's Core 2

The Kconfig help is a mouthful due to the inventiveness of Intel's
product naming department.

Mainly for the 64bit cache line sizes because gcc doesn't support
optimizing for core2 yet. However it will and then the kernel
should be ready by passing the right option

Also fix the old MPSC help text to confirm better to reality.
Signed-off-by: NAndi Kleen <ak@suse.de>
      71381998
  17. 17 11月, 2006 1 次提交
    • I
      [PATCH] x86_64: fix CONFIG_CC_STACKPROTECTOR build bug · ccf9ff52
      由 Ingo Molnar 提交于 
      on x86_64, the CONFIG_CC_STACKPROTECTOR build fails if used in a
distcc setup that has "CC" defined to "distcc gcc":

 gcc: gcc: linker input file unused because linking not done
 gcc: gcc: linker input file unused because linking not done
 gcc: gcc: linker input file unused because linking not done

this is because the gcc-x86_64-has-stack-protector.sh script
has a 2-parameters assumption. Fix this by passing $(CC) as
a single parameter.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Please-Use-Me-More: make randconfig
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ccf9ff52
  19. 22 10月, 2006 1 次提交
    • A
      [PATCH] x86: Use -maccumulate-outgoing-args · cdfce1f5
      由 Andi Kleen 提交于 
      This avoids some problems with gcc 4.x and earlier generating
invalid unwind information. In 4.1 the option is default
when unwind information is enabled.

And it seems to generate smaller code too, so it's probably
a good thing on its own. With gcc 4.0:

i386:
4683198  902112  480868 6066178  5c9002 vmlinux (before)
4449895  902112  480868 5832875  5900ab vmlinux (after)

x86-64:
4939761 1449584  648216 7037561  6b6279 vmlinux (before)
4854193 1449584  648216 6951993  6a1439 vmlinux (after)

On 4.1 it shouldn't make much difference because it is
default when unwind is enabled anyways.

Suggested by Michael Matz and Jan Beulich

Cc: jbeulich@novell.com
Signed-off-by: NAndi Kleen <ak@suse.de>
      cdfce1f5
  21. 26 9月, 2006 3 次提交
    • J
      [PATCH] i386/x86-64: Work around gcc bug with noreturn functions in unwinder · adf14236
      由 Jan Beulich 提交于 
      Current gcc generates calls not jumps to noreturn functions. When that happens the
return address can point to the next function, which confuses the unwinder.

This patch works around it by marking asynchronous exception
frames in contrast normal call frames in the unwind information.  Then teach
the unwinder to decode this.

For normal call frames the unwinder now subtracts one from the address which avoids
this problem.  The standard libgcc unwinder uses the same trick.

It doesn't include adjustment of the printed address (i.e. for the original
example, it'd still be kernel_math_error+0 that gets displayed, but the
unwinder wouldn't get confused anymore.

This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16
unfortunately because earlier binutils don't support .cfi_signal_frame

[AK: added automatic detection of the new binutils and wrote description]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      adf14236
    • A
      [PATCH] Add the -fstack-protector option to the CFLAGS · 4f7fd4d7
      由 Arjan van de Ven 提交于 
      Add a feature check that checks that the gcc compiler has stack-protector
support and has the bugfix for PR28281 to make this work in kernel mode.
The easiest solution I could find was to have a shell script in scripts/
to do the detection; if needed we can make this fancier in the future
without making the makefile too complex.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
CC: Andi Kleen <ak@suse.de>
CC: Sam Ravnborg <sam@ravnborg.org>
      4f7fd4d7
    • A
      [PATCH] x86: Detect CFI support in the assembler at runtime · e2414910
      由 Andi Kleen 提交于 
      ... instead of using a CONFIG option. The config option still controls
if the resulting executable actually has unwind information.

This is useful to prevent compilation errors when users select
CONFIG_STACK_UNWIND on old binutils and also allows to use
CFI in the future for non kernel debugging applications.

Cc: jbeulich@novell.com
Cc: sam@ravnborg.org
Signed-off-by: NAndi Kleen <ak@suse.de>
      e2414910
  23. 27 6月, 2006 1 次提交
  25. 10 4月, 2006 1 次提交
  27. 27 3月, 2006 1 次提交
  29. 26 3月, 2006 2 次提交
    • A
      [PATCH] x86_64: Basic reorder infrastructure · 4bdc3b7f
      由 Arjan van de Ven 提交于 
      This patch puts the infrastructure in place to allow for a reordering of
functions based inside the vmlinux. The general idea is that it is possible
to put all "common" functions into the first 2Mb of the code, so that they
are covered by one TLB entry. This as opposed to the current situation where
a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.

This is done by enabling the -ffunction-sections flag in gcc, which puts
each function in its own ELF section, so that the linker can then order them
in a way defined by the linker script.

As per previous discussions, Linus said he wanted a "static" list for this,
eg a list provided by the kernel tarbal, so that most people have the same
ordering at least. A script is provided to create this list based on
readprofile(1) output. The included list is provisional, and entirely biased
on my own testbox and me running a few kernel compiles and some other
things.

I think that to get to a better list we need to invite people to submit
their own profiles, and somehow add those all up and base the final list on
that. I'm willing to do that effort if this is ends up being the prefered
approach. Such an effort probably needs to be repeated like once a year or
so to adopt to the changing nature of the kernel.

Made it a CONFIG with default n because it increases link times
dramatically.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4bdc3b7f
    • A
      [PATCH] x86-64: Use -mtune=generic for generic kernels · dca99a38
      由 Andi Kleen 提交于 
      The upcomming gcc 4.2 got a new option -mtune=generic to tune
code for both common AMD and Intel CPUs. Use this option
when available for generic kernels.

On x86-64 it is used with CONFIG_GENERIC_CPU. On i386 it is
enabled with CONFIG_X86_GENERIC.  It won't affect the base
line CPU support in any ways and also not the minimum supported CPU.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dca99a38
  31. 06 3月, 2006 1 次提交
  33. 12 1月, 2006 2 次提交
  35. 10 1月, 2006 1 次提交
  37. 10 9月, 2005 1 次提交
  39. 29 7月, 2005 1 次提交
  41. 07 7月, 2005 1 次提交
    • A
      [CRYPTO] Add x86_64 asm AES · a2a892a2
      由 Andreas Steinmetz 提交于 
      Implementation:
===============
The encrypt/decrypt code is based on an x86 implementation I did a while
ago which I never published. This unpublished implementation does
include an assembler based key schedule and precomputed tables. For
simplicity and best acceptance, however, I took Gladman's in-kernel code
for table generation and key schedule for the kernel port of my
assembler code and modified this code to produce the key schedule as
required by my assembler implementation. File locations and Kconfig are
kept similar to the i586 AES assembler implementation.
It may seem a little bit strange to use 32 bit I/O and registers in the
assembler implementation but this gives the best code size. My
implementation takes one instruction more per round compared to
Gladman's x86 assembler but it doesn't require any stack for local
variables or saved registers and it is less serialized than Gladman's
code.
Note that all comparisons to Gladman's code were done after my code was
implemented. I did only use FIPS PUB 197 for the implementation so my
implementation is independent work.
If anybody has a better assembler solution for x86_64 I'll be pleased to
have my code replaced with the better solution.

Testing:
========
The implementation passes the in-kernel crypto testing module and I'm
running it without any problems on my laptop where it is mainly used for
dm-crypt.

Microbenchmark:
===============
The microbenchmark was done in userspace with similar compile flags as
used during kernel compile.
Encrypt/decrypt is about 35% faster than the generic C implementation.
As the generic C as well as my assembler implementation are both table
I don't really expect that there is much room for further
improvements though I'll be glad to be corrected here.
The key schedule is about 5% slower than the generic C implementation.
This is due to the fact that some more work has to be done in the key
schedule routine to fit the schedule to the assembler implementation.

Code Size:
==========
Encrypt and decrypt are together about 2.1 Kbytes smaller than the
generic C implementation which is important with regard to L1 cache
usage. The key schedule routine is about 100 bytes larger than the
generic C implementation.

Data Size:
==========
There's no difference in data size requirements between the assembler
implementation and the generic C implementation.

License:
========
Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only
(I'm  not going to change the license for my code). So I had to change
the module license for the x86_64 aes module from 'Dual BSD/GPL' to
'GPL' to reflect the most restrictive license within the module.
Signed-off-by: NAndreas Steinmetz <ast@domdv.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2a892a2
  43. 26 6月, 2005 1 次提交
  45. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      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!
      1da177e4