1. 13 2月, 2010 1 次提交
  2. 17 1月, 2010 1 次提交
    • R
      kernel.h: add BUILD_BUG_ON_NOT_POWER_OF_2() · cc8ef6eb
      Roland Dreier 提交于
      Add BUILD_BUG_ON_NOT_POWER_OF_2()
      
      When code relies on a constant being a power of 2:
      
      	#define FOO	512	/* must be a power of 2 */
      
      it would be nice to be able to do:
      
      	BUILD_BUG_ON(!is_power_of_2(FOO));
      
      However applying an inline function does not result in a compile-time
      constant that can be used with BUILD_BUG_ON(), so trying that gives
      results in:
      
      	error: bit-field '<anonymous>' width not an integer constant
      
      As suggested by akpm, rather than monkeying around with is_power_of_2()
      and risking gcc warts about constant expressions, just create a macro
      BUILD_BUG_ON_NOT_POWER_OF_2() to encapsulate this common requirement.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: David Dillow <dave@thedillows.org>
      Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cc8ef6eb
  3. 16 12月, 2009 3 次提交
  4. 15 12月, 2009 1 次提交
  5. 11 12月, 2009 1 次提交
    • S
      tracing: Add trace_dump_stack() · 03889384
      Steven Rostedt 提交于
      I've been asked a few times about how to find out what is calling
      some location in the kernel. One way is to use dynamic function tracing
      and implement the func_stack_trace. But this only finds out who is
      calling a particular function. It does not tell you who is calling
      that function and entering a specific if conditional.
      
      I have myself implemented a quick version of trace_dump_stack() for
      this purpose a few times, and just needed it now. This is when I realized
      that this would be a good tool to have in the kernel like trace_printk().
      
      Using trace_dump_stack() is similar to dump_stack() except that it
      writes to the trace buffer instead and can be used in critical locations.
      
      For example:
      
      @@ -5485,8 +5485,12 @@ need_resched_nonpreemptible:
       	if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
       		if (unlikely(signal_pending_state(prev->state, prev)))
       			prev->state = TASK_RUNNING;
      -		else
      +		else {
       			deactivate_task(rq, prev, 1);
      +			trace_printk("Deactivating task %s:%d\n",
      +				     prev->comm, prev->pid);
      +			trace_dump_stack();
      +		}
       		switch_count = &prev->nvcsw;
       	}
      
      Produces:
      
                 <...>-3249  [001]   296.105269: schedule: Deactivating task ntpd:3249
                 <...>-3249  [001]   296.105270: <stack trace>
       => schedule
       => schedule_hrtimeout_range
       => poll_schedule_timeout
       => do_select
       => core_sys_select
       => sys_select
       => system_call_fastpath
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      03889384
  6. 23 10月, 2009 1 次提交
    • C
      ratelimit: Make suppressed output messages more useful · 5c828713
      Christian Borntraeger 提交于
      Today I got:
      
        [39648.224782] Registered led device: iwl-phy0::TX
        [40676.545099] __ratelimit: 246 callbacks suppressed
        [40676.545103] abcdef[23675]: segfault at 0 ...
      
      as you can see the ratelimit message contains a function prefix.
      Since this is always __ratelimit, this wont help much.
      
      This patch changes __ratelimit and printk_ratelimit to print the
      function name that calls ratelimit.
      
      This will pinpoint the responsible function, as long as not several
      different places call ratelimit with the same ratelimit state at
      the same time. In that case we catch only one random function that
      calls ratelimit after the wait period.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <200910231458.11832.borntraeger@de.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5c828713
  7. 12 10月, 2009 1 次提交
  8. 23 9月, 2009 4 次提交
  9. 22 9月, 2009 1 次提交
    • I
      printk: Remove ratelimit.h from kernel.h · 3fff4c42
      Ingo Molnar 提交于
      Decouple kernel.h from ratelimit.h: the global declaration of
      printk's ratelimit_state is not needed, and it leads to messy
      circular dependencies due to ratelimit.h's (new) adding of a
      spinlock_types.h include.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3fff4c42
  10. 18 7月, 2009 2 次提交
  11. 26 6月, 2009 1 次提交
    • K
      x86: Add sysctl to allow panic on IOCK NMI error · 5211a242
      Kurt Garloff 提交于
      This patch introduces a new sysctl:
      
          /proc/sys/kernel/panic_on_io_nmi
      
      which defaults to 0 (off).
      
      When enabled, the kernel panics when the kernel receives an NMI
      caused by an IO error.
      
      The IO error triggered NMI indicates a serious system
      condition, which could result in IO data corruption. Rather
      than contiuing, panicing and dumping might be a better choice,
      so one can figure out what's causing the IO error.
      
      This could be especially important to companies running IO
      intensive applications where corruption must be avoided, e.g. a
      bank's databases.
      
      [ SuSE has been shipping it for a while, it was done at the
        request of a large database vendor, for their users. ]
      Signed-off-by: NKurt Garloff <garloff@suse.de>
      Signed-off-by: NRoberto Angelino <robertangelino@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      LKML-Reference: <20090624213211.GA11291@kroah.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5211a242
  12. 19 6月, 2009 1 次提交
  13. 17 6月, 2009 2 次提交
    • L
      printk: Add KERN_DEFAULT printk log-level · e28d7137
      Linus Torvalds 提交于
      This adds a KERN_DEFAULT loglevel marker, for when you cannot decide
      which loglevel you want, and just want to keep an existing printk
      with the default loglevel.
      
      The difference between having KERN_DEFAULT and having no log-level
      marker at all is two-fold:
      
       - having the log-level marker will now force a new-line if the
         previous printout had not added one (perhaps because it forgot,
         but perhaps because it expected a continuation)
      
       - having a log-level marker is required if you are printing out a
         message that otherwise itself could perhaps otherwise be mistaken
         for a log-level.
      Signed-of-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e28d7137
    • L
      printk: clean up handling of log-levels and newlines · 5fd29d6c
      Linus Torvalds 提交于
      It used to be that we would only look at the log-level in a printk()
      after explicit newlines, which can cause annoying problems when the
      previous printk() did not end with a '\n'. In that case, the log-level
      marker would be just printed out in the middle of the line, and be
      seen as just noise rather than change the logging level.
      
      This changes things to always look at the log-level in the first
      bytes of the printout. If a log level marker is found, it is always
      used as the log-level. Additionally, if no newline existed, one is
      added (unless the log-level is the explicit KERN_CONT marker, to
      explicitly show that it's a continuation of a previous line).
      Acked-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fd29d6c
  14. 16 6月, 2009 1 次提交
    • G
      debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem. · 156f5a78
      GeunSik Lim 提交于
      Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
      directory name to mount debugfs filesystem for ftrace according to
      ./Documentation/tracers/ftrace.txt file.
      
      And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
      existed in kernel source like ftrace, DRM, Wireless, Documentation,
      Network[sky2]files to mount debugfs filesystem.
      
      debugfs means debug filesystem for debugging easy to use by greg kroah
      hartman. "/sys/kernel/debug/" name is suitable as directory name
      of debugfs filesystem.
      - debugfs related reference: http://lwn.net/Articles/334546/
      
      Fix inconsistency of directory name to mount debugfs filesystem.
      
      * From Steven Rostedt
        - find_debugfs() and tracing_files() in this patch.
      Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com>
      Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
      Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
      Reviewed-by  : James Smart <james.smart@emulex.com>
      CC: Jiri Kosina <trivial@kernel.org>
      CC: David Airlie <airlied@linux.ie>
      CC: Peter Osterlund <petero2@telia.com>
      CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      CC: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      156f5a78
  15. 17 4月, 2009 1 次提交
  16. 03 4月, 2009 1 次提交
  17. 01 4月, 2009 1 次提交
  18. 29 3月, 2009 1 次提交
  19. 25 3月, 2009 2 次提交
  20. 13 3月, 2009 1 次提交
    • F
      tracing/core: bring back raw trace_printk for dynamic formats strings · 48ead020
      Frederic Weisbecker 提交于
      Impact: fix callsites with dynamic format strings
      
      Since its new binary implementation, trace_printk() internally uses static
      containers for the format strings on each callsites. But the value is
      assigned once at build time, which means that it can't take dynamic
      formats.
      
      So this patch unearthes the raw trace_printk implementation for the callers
      that will need trace_printk to be able to carry these dynamic format
      strings. The trace_printk() macro will use the appropriate implementation
      for each callsite. Most of the time however, the binary implementation will
      still be used.
      
      The other impact of this patch is that mmiotrace_printk() will use the old
      implementation because it calls the low level trace_vprintk and we can't
      guess here whether the format passed in it is dynamic or not.
      
      Some parts of this patch have been written by Steven Rostedt (most notably
      the part that chooses the appropriate implementation for each callsites).
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      48ead020
  21. 09 3月, 2009 1 次提交
    • I
      tracing: optimize trace_printk() · 7bffc23e
      Ingo Molnar 提交于
      Impact: micro-optimization
      
      trace_printk() does this unconditionally:
      
      	trace_printk_fmt = fmt;
      
      Where trace_printk_fmt is an entry into a global array. This is
      very SMP-unfriendly.
      
      So only write it once per bootup.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <1236356510-8381-5-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7bffc23e
  22. 07 3月, 2009 1 次提交
    • F
      tracing/core: drop the old trace_printk() implementation in favour of trace_bprintk() · 769b0441
      Frederic Weisbecker 提交于
      Impact: faster and lighter tracing
      
      Now that we have trace_bprintk() which is faster and consume lesser
      memory than trace_printk() and has the same purpose, we can now drop
      the old implementation in favour of the binary one from trace_bprintk(),
      which means we move all the implementation of trace_bprintk() to
      trace_printk(), so the Api doesn't change except that we must now use
      trace_seq_bprintk() to print the TRACE_PRINT entries.
      
      Some changes result of this:
      
      - Previously, trace_bprintk depended of a single tracer and couldn't
        work without. This tracer has been dropped and the whole implementation
        of trace_printk() (like the module formats management) is now integrated
        in the tracing core (comes with CONFIG_TRACING), though we keep the file
        trace_printk (previously trace_bprintk.c) where we can find the module
        management. Thus we don't overflow trace.c
      
      - changes some parts to use trace_seq_bprintk() to print TRACE_PRINT entries.
      
      - change a bit trace_printk/trace_vprintk macros to support non-builtin formats
        constants, and fix 'const' qualifiers warnings. But this is all transparent for
        developers.
      
      - etc...
      
      V2:
      
      - Rebase against last changes
      - Fix mispell on the changelog
      
      V3:
      
      - Rebase against last changes (moving trace_printk() to kernel.h)
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      LKML-Reference: <1236356510-8381-5-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      769b0441
  23. 05 3月, 2009 2 次提交
    • S
      tracing: add tracing_on/tracing_off to kernel.h · 2002c258
      Steven Rostedt 提交于
      Impact: cleanup
      
      The functions tracing_start/tracing_stop have been moved to kernel.h.
      These are not the functions a developer most likely wants to use
      when they want to insert a place to stop tracing and restart it from
      user space.
      
      tracing_start/tracing_stop was created to work with things like
      suspend to ram, where even calling smp_processor_id() can crash the
      system. The tracing_start/tracing_stop was used to stop the tracer from
      doing anything. These are still light weight functions, but add a bit
      more overhead to be able to stop the tracers. They also have no interface
      back to userland. That is, if the kernel calls tracing_stop, userland
      can not start tracing.
      
      What a developer most likely wants to use is tracing_on/tracing_off.
      These are very light weight functions (simply sets or clears a bit).
      These functions just stop recording into the ring buffer. The tracers
      don't even know that this happens except that they would receive NULL
      from the ring_buffer_lock_reserve function.
      
      Also, there's a way for the user land to enable or disable this bit.
      In debugfs/tracing/tracing_on, a user may echo "0" (same as tracing_off())
      or echo "1" (same as tracing_on()) into this file. This becomes handy when
      a kernel developer is debugging and wants tracing to turn off when it
      hits an anomaly. Then the developer can examine the trace, and restart
      tracing if they want to try again (echo 1 > tracing_on).
      
      This patch moves the prototypes for tracing_on/tracing_off to kernel.h
      and comments their use, so that a kernel developer will know how
      to use them.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      2002c258
    • I
      tracing: move utility functions from ftrace.h to kernel.h · 526211bc
      Ingo Molnar 提交于
      Make common utility functions such as trace_printk() and
      tracing_start()/tracing_stop() generally available to kernel
      code.
      
      Cc: Steven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      526211bc
  24. 06 2月, 2009 1 次提交
  25. 05 2月, 2009 1 次提交
    • I
      printk: introduce printk_once() · f036be96
      Ingo Molnar 提交于
      This pattern shows up frequently in the kernel:
      
        static int once = 1;
        ...
      
      		if (once) {
      			once = 0;
      			printk(KERN_ERR "message\n");
      		}
        ...
      
      So add a printk_once() helper macro that reduces this to a single line
      of:
      
      		printk_once(KERN_ERR "message\n");
      
      It works analogously to WARN_ONCE() & friends. (We use a macro not
      an inline because vararg expansion in inlines looks awkward and the
      macro is simple enough.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f036be96
  26. 09 1月, 2009 1 次提交
  27. 07 1月, 2009 2 次提交
  28. 16 11月, 2008 1 次提交
  29. 31 10月, 2008 1 次提交
  30. 29 10月, 2008 1 次提交