1. 03 5月, 2007 1 次提交
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 27 6月, 2006 1 次提交
  8. 10 4月, 2006 1 次提交
  9. 27 3月, 2006 1 次提交
  10. 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
  11. 06 3月, 2006 1 次提交
  12. 12 1月, 2006 2 次提交
  13. 10 1月, 2006 1 次提交
  14. 10 9月, 2005 1 次提交
  15. 29 7月, 2005 1 次提交
  16. 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
  17. 26 6月, 2005 1 次提交
  18. 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