Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 13 11月, 2007 1 次提交
    • S
      x86: do not use $(ARCH) when not needed · d746d647
      由 Sam Ravnborg 提交于 
      For x86 ARCH may say i386 or x86_64 and soon x86.
Rely on CONFIG_X64_32 to select between 32/64 or just
hardcode the value as appropriate.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
      d746d647
  3. 26 10月, 2007 1 次提交
  5. 24 10月, 2007 1 次提交
  7. 20 10月, 2007 2 次提交
  9. 18 10月, 2007 2 次提交
  11. 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
  13. 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
  15. 11 10月, 2007 13 次提交
  17. 19 8月, 2007 1 次提交
  19. 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
  21. 03 5月, 2007 2 次提交
  23. 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
  25. 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
  27. 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
  29. 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
  31. 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
  33. 27 6月, 2006 1 次提交
  35. 10 4月, 2006 1 次提交
  37. 27 3月, 2006 1 次提交
  39. 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
  41. 06 3月, 2006 1 次提交
  43. 12 1月, 2006 1 次提交