1. 13 12月, 2013 1 次提交
  2. 07 11月, 2013 1 次提交
  3. 21 9月, 2013 1 次提交
  4. 03 8月, 2013 1 次提交
  5. 06 6月, 2013 1 次提交
  6. 28 5月, 2013 3 次提交
  7. 25 5月, 2013 1 次提交
  8. 01 5月, 2013 1 次提交
  9. 23 3月, 2013 1 次提交
    • F
      printk: Provide a wake_up_klogd() off-case · dc72c32e
      Frederic Weisbecker 提交于
      wake_up_klogd() is useless when CONFIG_PRINTK=n because neither printk()
      nor printk_sched() are in use and there are actually no waiter on
      log_wait waitqueue.  It should be a stub in this case for users like
      bust_spinlocks().
      
      Otherwise this results in this warning when CONFIG_PRINTK=n and
      CONFIG_IRQ_WORK=n:
      
      	kernel/built-in.o In function `wake_up_klogd':
      	(.text.wake_up_klogd+0xb4): undefined reference to `irq_work_queue'
      
      To fix this, provide an off-case for wake_up_klogd() when
      CONFIG_PRINTK=n.
      
      There is much more from console_unlock() and other console related code
      in printk.c that should be moved under CONFIG_PRINTK.  But for now,
      focus on a minimal fix as we passed the merged window already.
      
      [akpm@linux-foundation.org: include printk.h in bust_spinlocks.c]
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Reported-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc72c32e
  10. 15 3月, 2013 5 次提交
    • R
      CONFIG_SYMBOL_PREFIX: cleanup. · b92021b0
      Rusty Russell 提交于
      We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
      "_".  But Al Viro broke this in "consolidate cond_syscall and
      SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
      do so.
      
      Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
      prefix it so something.  So various places define helpers which are
      defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
      
      1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
      2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
      3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
      4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
      5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
      6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
      7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
         CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
         for pasting.
      
      (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
      
      Let's solve this properly:
      1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
      2) Make linux/export.h usable from asm.
      3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
      4) Make everyone use them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: James Hogan <james.hogan@imgtec.com> (metag)
      b92021b0
    • S
      tracing: Add skip argument to trace_dump_stack() · c142be8e
      Steven Rostedt (Red Hat) 提交于
      Altough the trace_dump_stack() already skips three functions in
      the call to stack trace, which gets the stack trace to start
      at the caller of the function, the caller may want to skip some
      more too (as it may have helper functions).
      
      Add a skip argument to the trace_dump_stack() that lets the caller
      skip back tracing functions that it doesn't care about.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      c142be8e
    • S
      tracing: Optimize trace_printk() with one arg to use trace_puts() · 9d3c752c
      Steven Rostedt (Red Hat) 提交于
      Although trace_printk() is extremely fast, especially when it uses
      trace_bprintk() (writes args straight to buffer instead of inserting
      into string), it still has the overhead of calling one of the printf
      sprintf() functions, that need to scan the fmt string to determine
      what, if any args it has.
      
      This is a waste of precious CPU cycles if the printk format has no
      args but a single constant string. It is better to use trace_puts()
      which does not have the overhead of the fmt scanning.
      
      But wouldn't it be nice if the developer didn't have to think about
      such things, and the compile would just do it for them?
      
        trace_printk("this string has no args\n");
        [...]
        trace_printk("this sting does %p %d\n", foo, bar);
      
      As tracing is critical to have the least amount of overhead,
      especially when dealing with race conditions, and you want to
      eliminate any "Heisenbugs", you want the trace_printk() to use the
      fastest possible means of tracing.
      
      Currently the macro magic determines if it will use trace_bprintk()
      or if the fmt is a dynamic string (a variable), it will fall
      back to the slow trace_printk() method that does a full snprintf()
      before copying it into the buffer, where as trace_bprintk() only
      copys the pointer to the fmt and the args into the buffer.
      
      Well, now there's a way to spend some more Hogwarts cash and come
      up with new fancy macro magic.
      
        #define trace_printk(fmt, ...)			\
        do {							\
      	char _______STR[] = __stringify((__VA_ARGS__));	\
      	if (sizeof(_______STR) > 3)			\
      		do_trace_printk(fmt, ##__VA_ARGS__);	\
      	else						\
      		trace_puts(fmt);			\
        } while (0)
      
      The above needs a bit of explaining (both here and in the comments).
      
      By stringifying the __VA_ARGS__, we can, at compile time, determine
      the number of args that are being passed to trace_printk(). The extra
      parenthesis are required, otherwise the compiler complains about
      too many parameters for __stringify if there is more than one arg.
      
      When there are no args, the __stringify((__VA_ARGS__)) converts into
      "()\0", a string of 3 characters. Anything else, will be a string
      containing more than 3 characters. Now we assign that string to a
      dynamic char array, and then take the sizeof() of that array.
      If it is greater than 3 characters, we know trace_printk() has args
      and we need to do the full "do_trace_printk()" on them, otherwise
      it was only passed a single arg and we can optimize to use trace_puts().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven "The King of Nasty Macros!" Rostedt <rostedt@goodmis.org>
      9d3c752c
    • S
      tracing: Add trace_puts() for even faster trace_printk() tracing · 09ae7234
      Steven Rostedt (Red Hat) 提交于
      The trace_printk() is extremely fast and is very handy as it can be
      used in any context (including NMIs!). But it still requires scanning
      the fmt string for parsing the args. Even the trace_bprintk() requires
      a scan to know what args will be saved, although it doesn't copy the
      format string itself.
      
      Several times trace_printk() has no args, and wastes cpu cycles scanning
      the fmt string.
      
      Adding trace_puts() allows the developer to use an even faster
      tracing method that only saves the pointer to the string in the
      ring buffer without doing any format parsing at all. This will
      help remove even more of the "Heisenbug" effect, when debugging.
      
      Also fixed up the F_printk()s for the ftrace internal bprint and print events.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      09ae7234
    • S
      tracing: Add internal tracing_snapshot() functions · ad909e21
      Steven Rostedt (Red Hat) 提交于
      The new snapshot feature is quite handy. It's a way for the user
      to take advantage of the spare buffer that, until then, only
      the latency tracers used to "snapshot" the buffer when it hit
      a max latency. Now users can trigger a "snapshot" manually when
      some condition is hit in a program. But a snapshot currently can
      not be triggered by a condition inside the kernel.
      
      With the addition of tracing_snapshot() and tracing_snapshot_alloc(),
      snapshots can now be taking when a condition is hit, and the
      developer wants to snapshot the case without stopping the trace.
      
      Note, any snapshot will overwrite the old one, so take care
      in how this is done.
      
      These new functions are to be used like tracing_on(), tracing_off()
      and trace_printk() are. That is, they should never be called
      in the mainline Linux kernel. They are solely for the purpose
      of debugging.
      
      The tracing_snapshot() will not allocate a buffer, but it is
      safe to be called from any context (except NMIs). But if a
      snapshot buffer isn't allocated when it is called, it will write
      to the live buffer, complaining about the lack of a snapshot
      buffer, and then stop tracing (giving you the "permanent snapshot").
      
      tracing_snapshot_alloc() will allocate the snapshot buffer if
      it was not already allocated and then take the snapshot. This routine
      *may sleep*, and must be called from context that can sleep.
      The allocation is done with GFP_KERNEL and not atomic.
      
      If you need a snapshot in an atomic context, say in early boot,
      then it is best to call the tracing_snapshot_alloc() before then,
      where it will allocate the buffer, and then you can use the
      tracing_snapshot() anywhere you want and still get snapshots.
      
      Cc: Hiraku Toyooka <hiraku.toyooka.gu@hitachi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      ad909e21
  11. 21 1月, 2013 1 次提交
  12. 21 12月, 2012 1 次提交
    • G
      linux/kernel.h: fix DIV_ROUND_CLOSEST with unsigned divisors · c4e18497
      Guenter Roeck 提交于
      Commit 263a523d ("linux/kernel.h: Fix warning seen with W=1 due to
      change in DIV_ROUND_CLOSEST") fixes a warning seen with W=1 due to
      change in DIV_ROUND_CLOSEST.
      
      Unfortunately, the C compiler converts divide operations with unsigned
      divisors to unsigned, even if the dividend is signed and negative (for
      example, -10 / 5U = 858993457).  The C standard says "If one operand has
      unsigned int type, the other operand is converted to unsigned int", so
      the compiler is not to blame.  As a result, DIV_ROUND_CLOSEST(0, 2U) and
      similar operations now return bad values, since the automatic conversion
      of expressions such as "0 - 2U/2" to unsigned was not taken into
      account.
      
      Fix by checking for the divisor variable type when deciding which
      operation to perform.  This fixes DIV_ROUND_CLOSEST(0, 2U), but still
      returns bad values for negative dividends divided by unsigned divisors.
      Mark the latter case as unsupported.
      
      One observed effect of this problem is that the s2c_hwmon driver reports
      a value of 4198403 instead of 0 if the ADC reads 0.
      
      Other impact is unpredictable.  Problem is seen if the divisor is an
      unsigned variable or constant and the dividend is less than (divisor/2).
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reported-by: NJuergen Beisert <jbe@pengutronix.de>
      Tested-by: NJuergen Beisert <jbe@pengutronix.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: <stable@vger.kernel.org>	[3.7.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c4e18497
  13. 18 12月, 2012 1 次提交
  14. 12 12月, 2012 2 次提交
  15. 03 12月, 2012 1 次提交
    • J
      linux/kernel.h: define SYMBOL_PREFIX · cbdbf2ab
      James Hogan 提交于
      Define SYMBOL_PREFIX to be the same as CONFIG_SYMBOL_PREFIX if set by
      the architecture, or "" otherwise. This avoids the need for ugly #ifdefs
      whenever symbols are referenced in asm blocks.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      cbdbf2ab
  16. 01 11月, 2012 1 次提交
  17. 13 10月, 2012 1 次提交
  18. 19 9月, 2012 1 次提交
    • G
      linux/kernel.h: Fix warning seen with W=1 due to change in DIV_ROUND_CLOSEST · 263a523d
      Guenter Roeck 提交于
      After commit b6d86d3d (Fix DIV_ROUND_CLOSEST to support negative dividends),
      the following warning is seen if the kernel is compiled with W=1 (-Wextra):
      
      warning: comparison of unsigned expression >= 0 is always true
      
      The warning is due to the test '((typeof(x))-1) >= 0', which is used to detect
      if the variable type is unsigned. Research on the web suggests that the warning
      disappears if '>' instead of '>=' is used for the comparison.
      
      Tests after changing the macro along that line show that the warning is gone,
      and that the result is still correct:
      
      i=-4: DIV_ROUND_CLOSEST(i, 2)=-2
      i=-3: DIV_ROUND_CLOSEST(i, 2)=-2
      i=-2: DIV_ROUND_CLOSEST(i, 2)=-1
      i=-1: DIV_ROUND_CLOSEST(i, 2)=-1
      i=0: DIV_ROUND_CLOSEST(i, 2)=0
      i=1: DIV_ROUND_CLOSEST(i, 2)=1
      i=2: DIV_ROUND_CLOSEST(i, 2)=1
      i=3: DIV_ROUND_CLOSEST(i, 2)=2
      i=4: DIV_ROUND_CLOSEST(i, 2)=2
      
      Code size is the same as before.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      263a523d
  19. 02 9月, 2012 1 次提交
  20. 22 7月, 2012 1 次提交
  21. 01 6月, 2012 1 次提交
  22. 25 5月, 2012 1 次提交
  23. 24 4月, 2012 1 次提交
    • S
      tracing: Add percpu buffers for trace_printk() · 07d777fe
      Steven Rostedt 提交于
      Currently, trace_printk() uses a single buffer to write into
      to calculate the size and format needed to save the trace. To
      do this safely in an SMP environment, a spin_lock() is taken
      to only allow one writer at a time to the buffer. But this could
      also affect what is being traced, and add synchronization that
      would not be there otherwise.
      
      Ideally, using percpu buffers would be useful, but since trace_printk()
      is only used in development, having per cpu buffers for something
      never used is a waste of space. Thus, the use of the trace_bprintk()
      format section is changed to be used for static fmts as well as dynamic ones.
      Then at boot up, we can check if the section that holds the trace_printk
      formats is non-empty, and if it does contain something, then we
      know a trace_printk() has been added to the kernel. At this time
      the trace_printk per cpu buffers are allocated. A check is also
      done at module load time in case a module is added that contains a
      trace_printk().
      
      Once the buffers are allocated, they are never freed. If you use
      a trace_printk() then you should know what you are doing.
      
      A buffer is made for each type of context:
      
        normal
        softirq
        irq
        nmi
      
      The context is checked and the appropriate buffer is used.
      This allows for totally lockless usage of trace_printk(),
      and they no longer even disable interrupts.
      Requested-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      07d777fe
  24. 24 3月, 2012 2 次提交
  25. 21 3月, 2012 1 次提交
  26. 13 3月, 2012 1 次提交
  27. 05 3月, 2012 2 次提交
    • P
      kernel.h: doesn't explicitly use bug.h, so don't include it. · 6c03438e
      Paul Gortmaker 提交于
      This header isn't using bug.h infrastructure, but due to historical
      reasons, it was including it.  Removing it revealed several implicit
      dependencies (since kernel.h is everywhere) so we've fixed those 1st
      before deploying this change.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      6c03438e
    • P
      bug: consolidate BUILD_BUG_ON with other bug code · 35edd910
      Paul Gortmaker 提交于
      The support for BUILD_BUG in linux/kernel.h predates the
      addition of linux/bug.h -- with this chunk off separate,
      you can run into situations where a person gets a compile
      fail even when they've included linux/bug.h, like this:
      
          CC      lib/string.o
        lib/string.c: In function 'strlcat':
        lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
        make[2]: *** [lib/string.o] Error 1
        $
        $ grep linux/bug.h lib/string.c
        #include <linux/bug.h>
        $
      
      Since the above violates the principle of least surprise, move
      the BUG chunks from kernel.h to bug.h so it is all together.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      35edd910
  28. 21 2月, 2012 1 次提交
  29. 13 1月, 2012 3 次提交