1. 06 5月, 2014 1 次提交
  2. 14 2月, 2014 1 次提交
  3. 28 1月, 2014 1 次提交
  4. 02 5月, 2013 1 次提交
    • J
      linkage.h: fix build breakage due to symbol prefix handling · 126de6b2
      James Hogan 提交于
      Al's commit e1b5bb6d ("consolidate cond_syscall and SYSCALL_ALIAS
      declarations") broke the build on blackfin and metag due to the
      following code:
      
        #ifndef SYMBOL_NAME
        #ifdef CONFIG_SYMBOL_PREFIX
        #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
        #else
        #define SYMBOL_NAME(x) x
        #endif
        #endif
        #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
      
      __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get
      lines like this in kernel/sys_ni.s:
      
        .weak CONFIG_SYMBOL_PREFIXsys_quotactl
        .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall
      
      The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX:
      cleanup." cleans up the whole mess around symbol prefixes, so this patch
      just attempts to fix the build in the meantime.
      
      The intermediate definition of SYMBOL_NAME above isn't used and is
      incorrect when CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX
      is a quoted string literal, so define __SYMBOL_NAME directly depending
      on CONFIG_SYMBOL_PREFIX.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Mea-culpa-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: uclinux-dist-devel@blackfin.uclinux.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      126de6b2
  5. 04 3月, 2013 1 次提交
  6. 13 1月, 2012 3 次提交
  7. 24 5月, 2011 1 次提交
  8. 03 3月, 2010 2 次提交
  9. 21 9月, 2009 1 次提交
    • T
      kbuild: Don't define ALIGN and ENTRY when preprocessing linker scripts. · 42f29a25
      Tim Abbott 提交于
      Adding a reference to <linux/linkage.h> to x86's <asm/cache.h> causes
      the x86 linker script to have syntax errors, because the ALIGN and
      ENTRY keywords get redefined to the assembly implementations of those.
      One could fix this by adjusting the include structure, but I think any
      solution based on that approach would be fragile.
      
      Currently, it is impossible when writing a header to do something
      different for assembly files and linker scripts, even though there are
      clearly cases where one wants them to define macros differently for
      the two (ENTRY being an excellent example).
      So I think the right solution here is to introduce a new preprocessor
      definition, called LINKER_SCRIPT that is set along with __ASSEMBLY__
      for linker scripts, and to use that to not define ALIGN and ENTRY in
      linker scripts.
      I suspect we'll find other uses for this mechanism in
      the future.
      Signed-off-by: NTim Abbott <tabbott@ksplice.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42f29a25
  10. 27 6月, 2009 1 次提交
  11. 27 11月, 2008 1 次提交
  12. 14 10月, 2008 1 次提交
  13. 08 7月, 2008 1 次提交
    • J
      build: add __page_aligned_data and __page_aligned_bss · a7bf0bd5
      Jeremy Fitzhardinge 提交于
      Making a variable page-aligned by using
      __attribute__((section(".data.page_aligned"))) is fragile because if
      sizeof(variable) is not also a multiple of page size, it leaves
      variables in the remainder of the section unaligned.
      
      This patch introduces two new qualifiers, __page_aligned_data and
      __page_aligned_bss to set the section *and* the alignment of
      variables.  This makes page-aligned variables more robust because the
      linker will make sure they're aligned properly.  Unfortunately it
      requires *all* page-aligned data to use these macros...
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a7bf0bd5
  14. 24 5月, 2008 1 次提交
  15. 11 4月, 2008 3 次提交
    • H
      Fix "$(AS) -traditional" compile breakage caused by asmlinkage_protect · b0fac023
      Heiko Carstens 提交于
      git commit 54a01510 ("asmlinkage_protect
      replaces prevent_tail_call") causes this build failure on s390:
      
          AS      arch/s390/kernel/entry64.o
        In file included from arch/s390/kernel/entry64.S:14:
        include/linux/linkage.h:34: error: syntax error in macro parameter list
        make[1]: *** [arch/s390/kernel/entry64.o] Error 1
        make: *** [arch/s390/kernel] Error 2
      
      and some other architectures.  The reason is that some architectures add
      the "-traditional" flag to the invocation of $(AS), which disables
      variadic macro argument support.
      
      So just surround the new define with an #ifndef __ASSEMBLY__ to prevent
      any side effects on asm code.
      
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0fac023
    • L
      Add commentary about the new "asmlinkage_protect()" macro · d10d89ec
      Linus Torvalds 提交于
      It's really a pretty ugly thing to need, and some day it will hopefully
      be obviated by teaching gcc about the magic calling conventions for the
      low-level system call code, but in the meantime we can at least add big
      honking comments about why we need these insane and strange macros.
      
      I took my comments from my version of the macro, but I ended up deciding
      to just pick Roland's version of the actual code instead (with his
      prettier syntax that uses vararg macros).  Thus the previous two commits
      that actually implement it.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d10d89ec
    • R
      asmlinkage_protect replaces prevent_tail_call · 54a01510
      Roland McGrath 提交于
      The prevent_tail_call() macro works around the problem of the compiler
      clobbering argument words on the stack, which for asmlinkage functions
      is the caller's (user's) struct pt_regs.  The tail/sibling-call
      optimization is not the only way that the compiler can decide to use
      stack argument words as scratch space, which we have to prevent.
      Other optimizations can do it too.
      
      Until we have new compiler support to make "asmlinkage" binding on the
      compiler's own use of the stack argument frame, we have work around all
      the manifestations of this issue that crop up.
      
      More cases seem to be prevented by also keeping the incoming argument
      variables live at the end of the function.  This makes their original
      stack slots attractive places to leave those variables, so the compiler
      tends not clobber them for something else.  It's still no guarantee, but
      it handles some observed cases that prevent_tail_call() did not.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54a01510
  16. 14 2月, 2008 1 次提交
  17. 30 1月, 2008 2 次提交
  18. 22 10月, 2007 1 次提交
  19. 26 9月, 2006 1 次提交
    • P
      [PATCH] x86: error_code is not safe for kprobes · d28c4393
      Prasanna S.P 提交于
      This patch moves the entry.S:error_entry to .kprobes.text section,
      since code marked unsafe for kprobes jumps directly to entry.S::error_entry,
      that must be marked unsafe as well.
      This patch also moves all the ".previous.text" asm directives to ".previous"
      for kprobes section.
      
      AK: Following a similar i386 patch from Chuck Ebbert
      AK: Also merged Jeremy's fix in.
      
      +From: Jeremy Fitzhardinge <jeremy@goop.org>
      
      KPROBE_ENTRY does a .section .kprobes.text, and expects its users to
      do a .previous at the end of the function.
      
      Unfortunately, if any code within the function switches sections, for
      example .fixup, then the .previous ends up putting all subsequent code
      into .fixup.  Worse, any subsequent .fixup code gets intermingled with
      the code its supposed to be fixing (which is also in .fixup).  It's
      surprising this didn't cause more havok.
      
      The fix is to use .pushsection/.popsection, so this stuff nests
      properly.  A further cleanup would be to get rid of all
      .section/.previous pairs, since they're inherently fragile.
      
      +From: Chuck Ebbert <76306.1226@compuserve.com>
      
      Because code marked unsafe for kprobes jumps directly to
      entry.S::error_code, that must be marked unsafe as well.
      The easiest way to do that is to move the page fault entry
      point to just before error_code and let it inherit the same
      section.
      
      Also moved all the ".previous" asm directives for kprobes
      sections to column 1 and removed ".text" from them.
      Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      d28c4393
  20. 26 4月, 2006 1 次提交
  21. 24 3月, 2006 1 次提交
  22. 08 9月, 2005 1 次提交
    • P
      [PATCH] Kprobes: prevent possible race conditions generic · d0aaff97
      Prasanna S Panchamukhi 提交于
      There are possible race conditions if probes are placed on routines within the
      kprobes files and routines used by the kprobes.  For example if you put probe
      on get_kprobe() routines, the system can hang while inserting probes on any
      routine such as do_fork().  Because while inserting probes on do_fork(),
      register_kprobes() routine grabs the kprobes spin lock and executes
      get_kprobe() routine and to handle probe of get_kprobe(), kprobes_handler()
      gets executed and tries to grab kprobes spin lock, and spins forever.  This
      patch avoids such possible race conditions by preventing probes on routines
      within the kprobes file and routines used by kprobes.
      
      I have modified the patches as per Andi Kleen's suggestion to move kprobes
      routines and other routines used by kprobes to a seperate section
      .kprobes.text.
      
      Also moved page fault and exception handlers, general protection fault to
      .kprobes.text section.
      
      These patches have been tested on i386, x86_64 and ppc64 architectures, also
      compiled on ia64 and sparc64 architectures.
      Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d0aaff97
  23. 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