1. 22 2月, 2013 1 次提交
  2. 18 6月, 2012 1 次提交
    • S
      ftrace: Make all inline tags also include notrace · 93b3cca1
      Steven Rostedt 提交于
      Commit 5963e317 ("ftrace/x86: Do not change stacks in DEBUG when
      calling lockdep") prevented lockdep calls from the int3 breakpoint handler
      from reseting the stack if a function that was called was in the process
      of being converted for tracing and had a breakpoint on it. The idea is,
      before calling the lockdep code, do a load_idt() to the special IDT that
      kept the breakpoint stack from reseting. This worked well as a quick fix
      for this kernel release, until a certain config caused a lockup in the
      function tracer start up tests.
      
      Investigating it, I found that the load_idt that was used to prevent
      the int3 from changing stacks was itself being traced!
      
      Even though the config had CONFIG_OPTIMIZE_INLINING disabled, and
      all 'inline' tags were set to always inline, there were still cases that
      it did not inline! This was caused by CONFIG_PARAVIRT_GUEST, where it
      would add a pointer to the native_load_idt() which made that function
      to be traced.
      
      Commit 45959ee7 ("ftrace: Do not function trace inlined functions")
      only touched the 'inline' tags when CONFIG_OPMITIZE_INLINING was enabled.
      PARAVIRT_GUEST shows that this was not enough and we need to also
      mark always_inline with notrace as well.
      Reported-by: NFengguang Wu <wfg@linux.intel.com>
      Tested-by: NFengguang Wu <wfg@linux.intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      93b3cca1
  3. 24 3月, 2012 1 次提交
  4. 21 12月, 2011 1 次提交
    • S
      ftrace: Do not function trace inlined functions · 45959ee7
      Steven Rostedt 提交于
      When gcc inlines a function, it does not mark it with the mcount
      prologue, which in turn means that inlined functions are not traced
      by the function tracer. But if CONFIG_OPTIMIZE_INLINING is set, then
      gcc is allowed not to inline a function that is marked inline.
      
      Depending on the options and the compiler, a function may or may
      not be traced by the function tracer, depending on whether gcc
      decides to inline a function or not. This has caused several
      problems in the pass becaues gcc is not always consistent with
      what it decides to inline between different gcc versions.
      
      Some places should not be traced (like paravirt native_* functions)
      and these are mostly marked as inline. When gcc decides not to
      inline the function, and if that function should not be traced, then
      the ftrace function tracer will suddenly break when it use to work
      fine. This becomes even harder to debug when different versions of
      gcc will not inline that function, making the same kernel and config
      work for some gcc versions and not work for others.
      
      By making all functions marked inline to not be traced will remove
      the ambiguity that gcc adds when it comes to tracing functions marked
      inline. All gcc versions will be consistent with what functions are
      traced and having volatile working code will be removed.
      
      Note, only the inline macro when CONFIG_OPTIMIZE_INLINING is set needs
      to have notrace added, as the attribute __always_inline will force
      the function to be inlined and then not traced.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      45959ee7
  5. 25 5月, 2011 1 次提交
  6. 23 3月, 2011 1 次提交
  7. 10 8月, 2010 1 次提交
  8. 30 6月, 2010 1 次提交
  9. 02 11月, 2009 1 次提交
    • L
      compiler: Introduce __always_unused · 7b2a3513
      Li Zefan 提交于
      I wrote some code which is used as compile-time checker, and the
      code should be elided after compile.
      
      So I need to annotate the code as "always unused", compared to
      "maybe unused".
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <4AEE2CEC.8040206@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7b2a3513
  10. 13 3月, 2009 1 次提交
  11. 10 1月, 2009 1 次提交
  12. 03 1月, 2009 1 次提交
    • L
      Sanitize gcc version header includes · f153b821
      Linus Torvalds 提交于
       - include the gcc version-dependent header files from the generic gcc
         header file, rather than the other way around (iow: don't make the
         non-gcc header file have to know about gcc versions)
      
       - don't include compiler-gcc4.h for gcc 5 (for whenever it gets
         released).  That's just confusing and made us do odd things in the
         gcc4 header file (testing that we really had version 4!)
      
       - generate the name from the __GNUC__ version directly, rather than
         having a mess of #if conditionals.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f153b821
  13. 30 4月, 2008 1 次提交
  14. 26 4月, 2008 2 次提交
    • I
      generic: make optimized inlining arch-opt-in · 765c68bd
      Ingo Molnar 提交于
      Stephen Rothwell reported that linux-next did not build on powerpc64.
      
      make optimized inlining dependent on architecture opt-in.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      765c68bd
    • I
      x86: add optimized inlining · 60a3cdd0
      Ingo Molnar 提交于
      add CONFIG_OPTIMIZE_INLINING=y.
      
      allow gcc to optimize the kernel image's size by uninlining
      functions that have been marked 'inline'. Previously gcc was
      forced by Linux to always-inline these functions via a gcc
      attribute:
      
       #define inline	inline __attribute__((always_inline))
      
      Especially when the user has already selected
      CONFIG_OPTIMIZE_FOR_SIZE=y this can make a huge difference in
      kernel image size (using a standard Fedora .config):
      
         text    data     bss     dec           hex filename
         5613924  562708 3854336 10030968    990f78 vmlinux.before
         5486689  562708 3854336  9903733    971e75 vmlinux.after
      
      that's a 2.3% text size reduction (!).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      60a3cdd0
  15. 19 10月, 2007 1 次提交
  16. 17 10月, 2007 1 次提交
  17. 10 5月, 2007 1 次提交
    • D
      compiler: introduce __used and __maybe_unused · 0d7ebbbc
      David Rientjes 提交于
      __used is defined to be __attribute__((unused)) for all pre-3.3 gcc
      compilers to suppress warnings for unused functions because perhaps they
      are referenced only in inline assembly.  It is defined to be
      __attribute__((used)) for gcc 3.3 and later so that the code is still
      emitted for such functions.
      
      __maybe_unused is defined to be __attribute__((unused)) for both function
      and variable use if it could possibly be unreferenced due to the evaluation
      of preprocessor macros.  Function prototypes shall be marked with
      __maybe_unused if the actual definition of the function is dependant on
      preprocessor macros.
      
      No update to compiler-intel.h is necessary because ICC supports both
      __attribute__((used)) and __attribute__((unused)) as specified by the gcc
      manual.
      
      __attribute_used__ is deprecated and will be removed once all current
      code is converted to using __used.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0d7ebbbc
  18. 08 5月, 2007 1 次提交
  19. 12 2月, 2007 1 次提交
    • R
      [PATCH] extend the set of "__attribute__" shortcut macros · 82ddcb04
      Robert P. J. Day 提交于
      Extend the set of "__attribute__" shortcut macros, and remove identical
      (and now superfluous) definitions from a couple of source files.
      
      based on a page at robert love's blog:
      
      	http://rlove.org/log/2005102601
      
      extend the set of shortcut macros defined in compiler-gcc.h with the
      following:
      
      #define __packed                       __attribute__((packed))
      #define __weak                         __attribute__((weak))
      #define __naked                        __attribute__((naked))
      #define __noreturn                     __attribute__((noreturn))
      #define __pure                         __attribute__((pure))
      #define __aligned(x)                   __attribute__((aligned(x)))
      #define __printf(a,b)                  __attribute__((format(printf,a,b)))
      
      Once these are in place, it's up to subsystem maintainers to decide if they
      want to take advantage of them.  there is already a strong precedent for
      using shortcuts like this in the source tree.
      
      The ones that might give people pause are "__aligned" and "__printf", but
      shortcuts for both of those are already in use, and in some ways very
      confusingly.  note the two very different definitions for a macro named
      "ALIGNED":
      
        drivers/net/sgiseeq.c:#define ALIGNED(x) ((((unsigned long)(x)) + 0xf) & ~(0xf))
        drivers/scsi/ultrastor.c:#define ALIGNED(x) __attribute__((aligned(x)))
      
      also:
      
        include/acpi/platform/acgcc.h:
          #define ACPI_PRINTF_LIKE(c) __attribute__ ((__format__ (__printf__, c, c+1)))
      
      Given the precedent, then, it seems logical to at least standardize on a
      consistent set of these macros.
      Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      82ddcb04
  20. 11 1月, 2006 1 次提交
  21. 09 1月, 2006 1 次提交
  22. 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